linux « How To

BackBlaze Pod Petabyte scale storage solution at low price Settembre 23, 2009

Posted by installatore in Varie, linux.
add a comment

A inizio mese Backclaze una società che offre soluzioni di backup online ha rilasciato il progetto delle sue unità storage.

Dalle loro ricerche è emerso questi risultati in termini di costo di 1 Petabyte (1000Tb) con la tecnologia attualmente in commercio.

Come ben potete notare il costo della loro soluzione (ovviamente esclusa la parte software di gestione) è nettamente inferiore alle più note marche in commercio.

Un’unità da 67Tb ha un costo di 7867$ qui di seguito alcune immagini :

Il progetto è composto in totale da 45 dischi Sata da 1,5tb l’uno,che creano 3 volumi in RAID6 da 15 dischi ognuno (permette di perdere sino a 3 dischi senza perdere l’intero volume),su cui gira Debian 4 64bit e Jfs come file system (al momento il più prestante in questo genere di applicazioni),il tutto governato da interfaccia web,tramite le applicazioni proprietarie di backblaze.Tutto il “Pod” è assemblato con pezzi di facile reperibilità sul mercato,quindi in teoria praticabile da tutti.Sul sito è presente anche il modello in 3d dell’enclosure.

Un progetto davvero notevole complimenti a Backblaze.Di seguito il link al loro sito e articolo.

http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/

Show PHP errors in shared server Settembre 21, 2009

Posted by installatore in Varie, linux, security.
Tags: developers, errors, php
add a comment

Capita a volte sviluppando una nuova applicazione web,di dover vedere gli output degli errori generati da php nell’esecuzione della nostra applicazione,cosa che risulta difficoltosa se non possiamo accedere al file di configurazione php.ini del server (per esempio se abbiamo acquistato un servizio di hosting non dedicato o similare).

Come workaround possiamo aggiungere all’interno del nostro codice queste due semplici righe per avere l’output direttamente a video

error_reporting(E_ALL);
ini_set("display_errors", 1);

Mi raccomando ricordatevi di eliminare le righe una volta che la fase di sviluppo è completata per non mostrare eventuali errori ai vostri utenti

How to use chkconfig and service utility in Red Hat and CentOS distributions Settembre 20, 2009

Posted by installatore in linux, script.
Tags: centos, chkconfig, redhat, service
add a comment

In tutte le release di CentOS nonchè di RedHat troviamo due utility per gestire l’avvio e il kill dei servizi nei vari runlevel,il primo è chkconfig che ci permette di rendere automatica e di facile standardizzazione l’installazione come servizi delle proprie applicazioni,mentre con service possiamo startare/stoppare e restartare qualunque applicazione senza dover mettere il path

Per esempio vediamo l’init script di un programma preinstallato come OpenSSH.

[root@rac2 init.d]# head -8 sshd
#!/bin/bash
#
# Init file for OpenSSH server daemon
#
# chkconfig: 2345 55 25
# description: OpenSSH server daemon
#

Come possiamo vedere qui sopra vi è una linea chkconfig ,che verrà letta dai comandi a lui correlati.Adesso vediamo cosa significano i numeri di quella riga.

 chkconfig: 2345 55 25
            |    |   |_Priorità nella fase di kill del programma (es. il link in /etc/rc.d/rc0.d sarà K25sshd)
            |    |_____Priorità di start del programma    (es. il link in /etc/rc.d/rc3.d sarà S55sshd
            |__________Enumero i runlevels su cui deve essere attivo il programma

Quindi una volta configurata questa riga nei nostri init script,la andiamo a copiare in /etc/init.d quindi daremo i seguenti comandi:
Aggiungo i link nei runlevel specificati…

chkconfig sshd --add

Abilito il programma…

chkconfig sshd on

Quindi effettuo un listing per vedere se tutto ha funzionato correttamente…

chkconfig sshd --list

L’output sarà qualcosa del tipo…

[root@rac2 /]# chkconfig sshd --list
sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off

Adesso che tutto è configurato possiamo far partire il programma in questo modo…

[root@rac2 /]# service sshd start

Piuttosto che fare…

[root@rac2 rc2.d]# /etc/rc.d/init.d/sshd start

E per avere lo status di tutti i nostri servizi /programmi basterà lanciare…

[root@rac2 /]# service --status-all
apmd (pid 682) is running...
arpwatch is stopped
atd (pid 1151) is running...
cannaserver (pid 985) is running...
crond (pid 1003) is running...
cserver (pid 966) is running...
jserver (pid 946) is running...
gpm is stopped
identd is stopped
ipchains: Incompatible with this kernel
No status available for this package
kserver (pid 1023) is running...
lpd is stopped

Linux Firewall How to abort (cut) specific connections Settembre 13, 2009

Posted by installatore in linux, networking, script, security.
Tags: connections, cutter, iptraf, kill, netstat, ntop, tcpkill
add a comment

Alcune volte capita gestendo Firewall basati su distribuzioni Linux di dover killare eventuali connessioni superfluee,o non autorizzate o più semplicemente terminare vpn lasciate aperte dagli impiegati piuttosto che terminare connessioni con alti consumi di banda nonchè peer-to-peer.Per fare ciò non possiamo affidarci al solito comando netstat dovremmo imparare a utilizzare altri due comandi disponibili in linux.

Il primo comando disponibile è il comando tcpkill.

La sintassi del comando è:

tcpkill -i eth0 { expression }

Per esempio per poter killare tutte le connessioni in uscita sulla porta 21 (ftp) potremmo usare il comando nella seguente maniera.

tcpkill -i eth0 port 21

Oppure bloccare completamente tutte le connessioni da e per un determinato host.

tcpkill host 192.168.0.123

Altrimenti bloccare tutti i pacchetti tra un determinato host e tutti gli altri pc in rete ad esclusione del nostro.

tcpkill ip host 192.168.0.123 and not 192.168.0.15

Il secondo è cutter.

Per esempio se volessimo terminare tutte le connessioni da un’host al resto del mondo.

cutter 192.168.0.123

Se invece ci interessa terminare solo le connessioni ssh.

cutter 192.168.0.123 22

Se vogliamo essere più specifici e bloccare tutte le connessioni ssh dal 192.168.0.123 al server remoto 123.123.123.123 la sintassi sarà la seguente.

cutter 123.123.123.123 192.168.0.123 22

Direi che questi 2 utilissimi comandi se usati in aggiunta ad iptraf o ad altri programmi di monitoring come ntop permettono anche l’automazione di eventuali operazioni ripetitive come la disconnessione do tutte le vpn alla fine del turno di lavoro.

Linux Monitor / Healthcheck script Settembre 3, 2009

Posted by installatore in Varie, linux, networking, script, solaris.
Tags: admin, check, health, linux, monitor, sys, sysadmin
add a comment

In questo articolo,descrivo come tramite l’uso dei comandi della shell di linux possiamo crearci uno script da schedulare successivamente con cron,per monitorare lo stato di salute dei nostri server.La funzionalità dello script è molto semplice ,sicuramente può essere migliorato.

Come prima cosa partirei controllando che il/i filesystem del nostro server non siano pieni .

[root@rac2 ~]# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/VolGroup00-LogVol00

14G 13G 775M 95% /

/dev/sda1 99M 19M 76M 20% /boot

tmpfs 502M 300M 202M 60% /dev/shm

Controlliamo inoltre gli ultimi login effettuati sulla macchina,come si dice….la prudenza non è mai troppa…

[root@rac2 ~]# last | head -20

root pts/3 192.168.0.8 Tue Aug 18 09:20 still logged in

oracle pts/3 :0.0 Tue Aug 18 09:17 – 09:20 (00:02)

oracle pts/3 :0.0 Tue Aug 18 08:19 – 09:16 (00:56)

oracle pts/2 :0.0 Tue Aug 18 07:08 still logged in

oracle :0 Tue Aug 18 07:08 still logged in

oracle :0 Tue Aug 18 07:08 – 07:08 (00:00)

root pts/1 openfiler1 Tue Aug 18 07:04 still logged in

reboot system boot 2.6.18-128.4.1.e Tue Aug 18 06:57 (02:25)

root pts/1 :0.0 Tue Aug 18 06:44 – down (00:11)

root pts/2 openfiler1 Tue Aug 18 06:22 – down (00:32)

root pts/1 :0.0 Tue Aug 18 06:15 – 06:43 (00:28)

root :0 Tue Aug 18 06:14 – down (00:40)

root :0 Tue Aug 18 06:14 – 06:14 (00:00)

reboot system boot 2.6.18-128.4.1.e Tue Aug 18 06:10 (00:45)

root pts/1 :0.0 Tue Aug 18 05:49 – down (00:19)

root pts/1 :0.0 Tue Aug 18 05:47 – 05:48 (00:00)

root pts/1 :0.0 Sun Aug 16 16:36 – 05:46 (1+13:10)

root pts/2 :0.0 Sun Aug 16 16:26 – down (1+13:41)

root pts/1 :0.0 Sun Aug 16 16:24 – 16:36 (00:12)

root :0 Sun Aug 16 16:23 – down (1+13:45)

Un’altra cosa da controllare soprattutto sui sistemi esposti su internet,è la grandezza della cartella temporanea e relativi file,molto spesso al suo interno si annidano rootkit o altri malware.Nel mio caso la cartella temporanea era /tmp

[root@rac2 ~]# du -h /tmp

8.0K /tmp/gconfd-root

4.0K /tmp/keyring-JuVYH2

4.0K /tmp/.oracle

16K /tmp

Controlliamo anche lo stato dell’hardware della scheda madre andando a fare un grep su tutte le voci che contegono state o status.

[root@rac2 ~]# dmidecode |grep -B 2 Stat

Serial Number: …..

Asset Tag:

Boot-up State: Safe

Power Supply State: Safe

Thermal State: Safe

Security Status: None

–

Max Speed: 5200 MHz

Current Speed: 2400 MHz

Status: Populated, Enabled

–

On Board Device Information

Type: Ethernet

Status: Enabled

–

On Board Device Information

Type: Sound

Status: Enabled

–

On Board Device Information

Type: Other

Status: Enabled

–

Access Method: Memory-mapped physical 32-bit address

Access Address: 0xFFF81000

Status: Valid, Not Full

–

Handle 0×1800, DMI type 24, 5 bytes.

Hardware Security

Power-On Password Status: Enabled

Keyboard Password Status: Not Implemented

Administrator Password Status: Enabled

Front Panel Reset Status: Not Implemented

–

Cooling Device

Type: Fan

Status: OK

–

Cooling Device

Type: Fan

Status: OK

–

Cooling Device

Type: Fan

Status: OK

–

Handle 0×2000, DMI type 32, 11 bytes.

System Boot Information

Status: No errors detected

A questo punto diamo un’occhiata allo stato dei pacchetti droppati e agli errori di trasmissione e ricezione sulle interfacce di rete.In linea di massima questi valori non dovrebbero crescere in maniera esorbitante nell’arco della giornata.

[root@rac2 ~]# ifconfig

eth4 Link encap:Ethernet HWaddr 00:0C:29:2D:6F:3E

inet addr:192.168.0.102 Bcast:192.168.0.255 Mask:255.255.255.0

inet6 addr: fe80::20c:29ff:fe2d:6f3e/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:2814028 errors:0 dropped:0 overruns:0 frame:0

TX packets:383162 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:2263618394 (2.1 GiB) TX bytes: 372588412946 (347 GiB)

Base address:0×2000 Memory:d8940000-d8960000

Oltre al comando ifconfig per controllare la parte “fisica” del collegamento in rete possiamo usare ethtool.

[root@rac2 ~]# ethtool eth0

Settings for eth0:

Supported ports: [ TP ]

Supported link modes: 10baseT/Half 10baseT/Full

100baseT/Half 100baseT/Full

1000baseT/Full

Supports auto-negotiation: Yes

Advertised link modes: 10baseT/Half 10baseT/Full

100baseT/Half 100baseT/Full

1000baseT/Full

Advertised auto-negotiation: Yes

Speed: 1000Mb/s

Duplex: Full

Port: Twisted Pair

PHYAD: 0

Transceiver: internal

Auto-negotiation: on

Supports Wake-on: d

Wake-on: d

Current message level: 0×00000007 (7)

Link detected: yes

Tramite lm_sensors possiamo ottenere i valori di elettricità e di temperatura di alcuni componenti della scheda madre della nostra macchina,quindi se non lo avete già fatto bisogna installare lm_sensors e lanciare il comando sensors-detect e seguire la procedura guidata per la prima configurazione.

[root@rac2]# sensors

lm85b-i2c-0-2e

Adapter: SMBus I801 adapter at c400

V1.5: +1.47 V (min = +1.42 V, max = +1.58 V)

VCore: +1.49 V (min = +1.45 V, max = +1.60 V)

V3.3: +3.33 V (min = +3.13 V, max = +3.47 V)

V5: +5.03 V (min = +4.74 V, max = +5.26 V)

V12: +12.25 V (min = +11.38 V, max = +12.62 V)

CPU_Fan: 2386 RPM (min = 4000 RPM) ALARM

fan2: 0 RPM (min = 0 RPM)

fan3: 0 RPM (min = 0 RPM)

fan4: 300 RPM (min = 0 RPM)

CPU: +29°C (low = +10°C, high = +50°C)

Board: +29°C (low = +10°C, high = +35°C)

Remote: +28°C (low = +10°C, high = +35°C)

CPU_PWM: 255

Fan2_PWM: 255

Fan3_PWM: 77

vid: +1.525 V (VRM Version 9.0)

Bisogna inoltre controllare eventuali errori hardware ai dischi tramite dmesg,in dmesg trovate anche altri errori relativi alle periferiche,qui di seguito lo utilizzo con un grep per i dischi,ovviamente potete personalizzare il grep a vostra discrezione.

[root@rac2 ~]# dmesg | grep sda

SCSI device sda: 33554432 512-byte hdwr sectors (17180 MB)

sda: Write Protect is off

sda: Mode Sense: 5d 00 00 00

sda: cache data unavailable

sda: assuming drive cache: write through

SCSI device sda: 33554432 512-byte hdwr sectors (17180 MB)

sda: Write Protect is off

sda: Mode Sense: 5d 00 00 00

sda: cache data unavailable

sda: assuming drive cache: write through

sda: sda1 sda2

sd 0:0:0:0: Attached scsi disk sda

EXT3 FS on sda1, internal journal

Quindi controlliamo il numero di processi “zombie” e quale tra i processi sta consumando più ram e cpu giusto per vedere che non ci siano problemi (il numero dei processi zombie non deve mai essere troppo alto).

[root@rac2]# top -bn 2 >> /tmp/top.txt

top – 09:52:46 up 130 days, 5 users, load average: 0.13, 0.21, 0.27

Tasks: 159 total, 3 running, 156 sleeping, 0 stopped, 0 zombie

Cpu(s): 0.0%us, 1.0%sy, 0.0%ni, 95.0%id, 3.6%wa, 0.0%hi, 0.3%si, 0.0%st

Mem: 1027004k total, 936852k used, 90152k free, 20292k buffers

Swap: 2064376k total, 71652k used, 1992724k free, 681484k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1314 root 15 0 12740 1108 804 R 1.0 0.1 0:00.16 top

1274 root 15 0 88948 3328 2588 R 0.3 0.3 0:00.27 sshd

1 root 15 0 10344 508 476 S 0.0 0.0 0:01.22 init

2 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0

3 root 34 19 0 0 0 S 0.0 0.0 0:00.05 ksoftirqd/0

4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0

5 root 10 -5 0 0 0 S 0.0 0.0 0:05.58 events/0

6 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khelper

15 root 10 -5 0 0 0 S 0.0 0.0 0:00.01 kthread

19 root 10 -5 0 0 0 S 0.0 0.0 0:08.29 kblockd/0

20 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid

205 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/0

208 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khubd

A questo punto spiegati tutti i singoli comandi possiamo crearci uno script da lanciare tutti i giorni tramite cron,in modo tale che ci invii anche una mail con il resoconto di tutti i comandi.

#!/bin/sh

# monitor script linux v1

uname -a > /tmp/mhc.txt

echo “—————————-”>>/tmp/mhc.txt

df -h >> /tmp/mhc.txt

last |head -10 >> /tmp/mhc.txt

echo “—————————-”>>/tmp/mhc.txt

du -h /tmp >> /tmp/mhc.txt

echo “—————————-”>>/tmp/mhc.txt

ethtool eth0 >> /tmp/mhc.txt

echo “—————————-”>>/tmp/mhc.txt

ifconfig eth0 >> /tmp/mhc.txt

echo “—————————-”>>/tmp/mhc.txt

dmidecode |grep -B 2 Stat >> /tmp/mhc.txt

echo “—————————-”>>/tmp/mhc.txt

sensors >> /tmp/mhc.txt

echo “—————————-”>>/tmp/mhc.txt

top -bn 2 >> /tmp/mhc.txt

echo “—————————-”>>/tmp/mhc.txt

smartctl -d ata -iH /dev/sda >> /tmp/mhc.txt

smartctl -d ata -iH /dev/sdb >> /tmp/mhc.txt

echo “—————————-”>>/tmp/mhc.txt

dmesg |grep sda >> /tmp/mhc.txt

dmesg |grep sdb >> /tmp/mhc.txt

echo “—————————-”>>/tmp/mhc.txt

cat /tmp/mhc.txt |mail -s server-health-check your@email.com

[root@rac2 ~]# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/VolGroup00-LogVol00

14G 13G 775M 95% /

/dev/sda1 99M 19M 76M 20% /boot

tmpfs 502M 300M 202M 60% /de

Active/Active cluster with Heartbeat + Mon for a Server Application Aprile 26, 2009

Posted by installatore in linux, networking, script.
Tags: dns, linux, rhel, server
add a comment

In questo articolo spiegherò brevemente come poter creare un cluster a 2 nodi Active/Active per un applicazione server attraverso anche l’uso di un record DNS Round Robyn,che andrà a smistare il traffico.

Per questa configurazione ho scelto di avere 2 indirizzi Ip virtuali (a cui punterà il round robyn) che potranno effettuare il failover su entrambi i nodi del nostro cluster.Per creare i 2 ip virtuali e lanciare mon, utilizzeremo heartbeat http://www.linux-ha.org/ .

Per gestire le risorse clusterizzate utilizzeremo mon http://mon.wiki.kernel.org/ .Mon avrà il compito di monitorare i nostri 2 nodi e tramite lo script tcp.monitor monitorare la porta che la nostra applicazione terrà aperta in ascolto.

Prima di tutto andiamo a configurare il file /etc/hosts inserendo i nomi host dei nostri server su entrambi i nodi.

10.0.0.2 nodoclu1

10.0.0.3 nodoclu2

Quindi procediamo con l’installazione di heartbeat e di mon,tramite i sorgenti o i packages scaricati dai relativi siti.Ipotizzerò che le cartelle di installazione per i 2 programmi siano /etc/ha.d (per heartbeat) e /etc/mon (per mon).

Cominciamo con il configurare su entrambi i nodi il file /etc/ha.d/ha.cf nel seguente modo:

# Logging

debug 0

debugfile /var/log/ha-debug

use_logd false

logfacility daemon

logfile /var/log/ha-log

# Misc Options

traditional_compression off

compression bz2

coredumps true

# Communications (scelgo su quali interfacce e su che porta configurare le comunicazioni interne tra i due nodi)

udpport 691

bcast eth0

bcast eth1

# Thresholds (in seconds)

keepalive 1

warntime 6

initdead 5 #(un nodo viene indicato come failed dopo 5 secondi)

deadtime 9 #(un nodo viene indicato come morto dopo 9 secondi)

ping 10.0.0.1 #(per verificare che la rete pubblica sia sù pingo il mio gateway)

node nodoclu1,nodoclu2 #(i nodi che appartengono al cluster)

auto_failback off #(gestisco il fail back delle risorse con mon,quindi questo lo lascio a off)

respawn hacluster /usr/lib64/heartbeat/ipfail #(indica il programma che controlla le interfacce di rete)

In questo file abbiamo quindi specificato i parametri di partenza per heartbeat,non ci resta che andare ad editare anche il file /etc/ha.d/haresources per poter configurare le risorse che vogliamo clusterizzare.

nodoclu1 10.0.0.10 mon_script

nodoclu2 10.0.0.20

Abbiamo quindi specificato che sul nodoclu1 sarà presente l’ip virtuale 10.0.0.10 e la risorsa mon_script ,che sarebbe lo script di avvio di mon,che dovrà essere inserito in /etc/ha.d/resource.d .Mentre per il nodoclu2 girerà solamente un altro ip virtuale.Ovviamente entrambi i nodi possono ospitare tutte le risorse qui descritte (2 ip virtuali + mon).Qui di seguito lo script mon_script….

#!/bin/sh

# start/stop the mon server

# processname: mon

# config: /etc/mon/mon.cf

# pidfile: /var/run/mon.pid

PATH=/bin:/usr/bin:/sbin:/usr/sbin

export PATH

# Source function library.

. /etc/rc.d/init.d/functions

# See how we were called.

case “$1″ in

start)

echo -n “Starting mon daemon: “

# daemon /etc/mon/mon -c /etc/mon/mon.cf

/etc/mon/mon -f -c /etc/mon/mon.cf

echo

touch /var/lock/subsys/mon

;;

stop)

echo -n “Stopping mon daemon: “

killproc mon

echo

rm -f /var/lock/subsys/mon

;;

status)

base=”mon”

pid=`pidof -o $$ -o $PPID -o %PPID -x ${base}`

if [ -n "$pid" ]; then

echo “running”

else

echo “stopped”

;;

monitor)

base=”mon”

pid=`pidof -o $$ -o $PPID -o %PPID -x ${base}`

if [ -n "$pid" ]; then

echo “running”

else

echo “stopped”

exit 7

;; restart)

killall -HUP mon

;;

echo “Usage: mon {start|stop|status|restart|monitor}”

exit 1

esac

exit 0

A questo punto possiamo lanciare heartbeat su entrambi i nodi per controllare che vengano caricate tutte le nostre risorse (/etc/init.d/heartbeat start).Quindi possiamo partire configurando il file /etc/mon/mon.cf

alertdir = /etc/mon/alert.d

mondir = /etc/mon/mon.d

logdir = /etc/mon

maxprocs = 20

histlength = 100

randstart = 60s

hostgroup nodo1 10.0.0.2

hostgroup nodo2 10.0.0.3

watch nodo1

service tcp

interval 5s

monitor tcp.monitor -p 3000 10.0.0.2 #-p portatcp indirizzonodo1

period wd {Mon-Sun}

alert ha_sall.alert #appena non mi risponde per 2 volte il server lancio /usr/lib64/heartbeat/hb_standby all

upalert ha_tloc.alert #appena torna su il server lancio /usr/lib64/heartbeat/hb_takeover local

alertafter 2

no_comp_alerts

watch nodo2

service tcp

interval 5s

monitor tcp.monitor -p 3000 10.0.0.3 #-p portatcp indirizzonodo2

period wd {Mon-Sun}

alert ha_tall.alert # appena non mi risponde per 2 volte il server lancio /usr/lib64/heartbeat/hb_takeover all

upalert ha_sfor.alert #appena torna su lancio /usr/lib64/heartbeat/hb_standby foreign

alertafter 2

no_comp_alerts

I file come ha_sfor.alert sono contenuti sotto /etc/mon/alert.d e non sono altro che file script con il comando scritto affianco.Ovviamente questa è la configurazione del nodo 1 quindi sul nodo 2 dovrò scambiare tutto ciò che riguarda col nodo1 con il nodo2 e viceversa.In pratica monitorizza se la porta 3000 sugli indirizzi ip indicati è aperta se non lo è esegue il file di alert dopo 2 volte che non risponde (alertafter 2),se la porta torna disponibile allora scatta l’upalert.Con questa configurazione la mia applicazione aveva tra l’alert e il failover delle risorse solo 5 secondi direi un risultato molto soddisfacente.

Aggiungere la sincronizzazione NTP su Linux Agosto 14, 2008

Posted by installatore in linux.
Tags: crond, crontab, linux, ntp, server
add a comment

Per far si che il nostro server si sincronizzi ogni tot tempo con il server ntp andiamo ad aggiungere in crontab…

/etc/crontab

la seguente linea

00 */1 * * * root ntpdate -s indirizzoserverntp

riavvio il cron daemon con….

/etc/init.d/crond (cron) restart

Aggiungere DNS su Linux Agosto 14, 2008

Posted by installatore in linux.
Tags: dns, linux
add a comment

Per inserire dei server dns locali su Linux andiamo ad editare il file

/etc/resolv.conf

Andando a inserire la seguente stringa….

nameserver indirizzoipdelprimodns
nameserver indirizzoipdelsecondodns
search local

Red Hat Linux e vnc…una vera lotta!! Luglio 31, 2008

Posted by installatore in linux.
Tags: 4, 5, linux, remote, rhel, server, vnc
add a comment

Per chi come me,si è avvicinato da poco al mondo di linux e si è trovato di fronte a dover abilitare il server vnc su una macchina con Red Hat,avrà sicuramente notato come dopo aver dato i classici comandi…

./vncserver [avvio il server vnc]

passwd [setto la password per vnc]

…e collegandosi da remoto trovava come sorpresa una schermata che non era affatto quella dell’xserver desiderato.Dopo averci sbattuto un pò la testa (sono alle prime armi ehehe ) ho scoperto che in fondo al file /home/nomeutente/.vnc/startup bisognava aggiungere in coda…

gnome-session

Una cavolata per i più ,ma a me è costata mezzagiornata

Aggiungiamo un pò di programmi all’Asus EEE pc Luglio 30, 2008

Posted by installatore in linux.
Tags: asus, eee, eeepc, linux, repository, xandros
add a comment

Come avrete sicuramente notato l’installazione di Xandros è molto leggera con programmi,che possono bastare per un utente di medio livello….per chi ha bisogno di poter installare altri programmi vediamo insieme come poter aggiungere un repository differente da quello predefinito di Xandros per poter installare nuove funzionalità al nostro EEE pc.

Come prima cosa andiamo ad editare il seguente file:

/etc/apt/sources.list

il quale contiene la lista dei repository e andiamo ad aggiungere i seguenti repository:

deb http://xnv4.xandros.com/xs2.0/upkg-srv2 etch main contrib non-free
deb http://dccamirror.xandros.com/dccri/ dccri-3.0 main
deb http://www.geekconnection.org/ xandros4 main
deb http://download.tuxfamily.org/eeepcrepos/ p701 main etch
Quindi creiamo il seguente file /etc/apt/preferences che servirà a dare una priorità alle 
applicazioni provenienti dal repository standard di Xandros predefiniti...
all'interno andiamo a inserire questi dati...
Package: *
Pin: origin update.eeepc.asus.com
Pin-Priority: 950

Package: *
Pin: origin
Pin-Priority: 925

Package: *
Pin: origin xnv4.xandros.com
Pin-Priority: 900

Package: *
Pin: origin dccamirror.xandros.com
Pin-Priority: 850

Package: *
Pin: origin www.geekconnection.org
Pin-Priority: 750

Package: *
Pin: release a=stable
Pin-Priority: 700

Package: *
Pin: release a=testing
Pin-Priority: 650

Package: *
Pin: release a=unstable
Pin-Priority: 600
A questo punto aggiorniamo il metadata del repository
$ sudo apt-get update

Tramite apt possiamo per esempio installare una nuova applicazione

$ sudo apt-get install nomeapplicazione

Oppure scaricare direttamente gli aggiornamenti di Xandros
$ sudo apt-get -s dist-upgrade

How To