de vegades iniciem un tarees via ssh que han de tenir continuitat i no podem perdre la sessió, una solució es utiltizar screen, que normalment ve instal·lat a les distribucions o tenim informació a http://www.gnu.org/software/screen
per iniciar screen posem
#screen
i li donem a l'espai, ara estem a l'interprete de screen
si volem veure la llista de screen que tenim actives
ies-sabadell:~# screen -list
There are screens on:
5421.pts-0.ies-sabadell (06/11/10 23:32:35) (Attached)
5408.pts-0.ies-sabadell (06/11/10 23:31:32) (Detached)
2 Sockets in /var/run/screen/S-root.
en aquest tenim dos sessions obertes d'screen i la que està activa és la primera, la sintaxis es pid.terminal.nom i amb aquestes dades recuperarem la sessió screen més tard.
per fer la prova llenço
rsync -e ssh --progress --delete -lprtz /srv user@yyy.yyy.yyy.yyy:/backups/server-moodle/srv2
que estarà una bona estona copiant al servidor donat que és el primer backup en aquest disc nou
donat que no puc estar tot el temps davant el terminal tanco la sessió screen
Ctrl+A i despres D
i tornem a l'interpretre normal que també tanco.
Pasades 1 hora em torno a connectar
ssh ies-sabadell.xtec.net
ies-sabadell:~# screen -r
There are several suitable screens on:
5421.pts-0.ies-sabadell (06/11/10 23:32:35) (Detached)
5408.pts-0.ies-sabadell (06/11/10 23:31:32) (Detached)
Type "screen [-d] -r [pid.]tty.host" to resume one of them.
està clar que screen -r em retorna les screen que s'estàn executant
per tornar-me a connectar faig screen -r 5421.pts-0.ies-sabadell
diumenge, 7 de novembre del 2010
dissabte, 6 de novembre del 2010
repetició de tasques via crontab i rsync
per realitzar els backups de matinada el que utilitzo es rsync amb l'idea de que em gestioni la informació comprimida i només els canvis realitzats,
crontab -e
30 4 * * * rsync -e ssh --progress --delete -lprtz /srv user@yyy.yyy.yyy.yyy:/home/srv2
0 5 * * * rsync -e ssh --progress --delete -lprtz /var/lib/mysql user@yyy.yyy.yyy.yyy:/opt/lampp/var/mysql
30 5 * * * rsync -e ssh --progress --delete -lprtz /backup/mysql-backup user@yyy.yyy.yyy.yyy:/home/backups-mysql
45 5 * * * rsync -e ssh --progress --delete -lprtz /mio/backup-moodle user@yyy.yyy.yyy.yyy:/home/backups-moodle
això farà que ha diferents hores, a partir de les 4:30h comenci a fer backups només de les coses que s'han modificat.
crontab -e
30 4 * * * rsync -e ssh --progress --delete -lprtz /srv user@yyy.yyy.yyy.yyy:/home/srv2
0 5 * * * rsync -e ssh --progress --delete -lprtz /var/lib/mysql user@yyy.yyy.yyy.yyy:/opt/lampp/var/mysql
30 5 * * * rsync -e ssh --progress --delete -lprtz /backup/mysql-backup user@yyy.yyy.yyy.yyy:/home/backups-mysql
45 5 * * * rsync -e ssh --progress --delete -lprtz /mio/backup-moodle user@yyy.yyy.yyy.yyy:/home/backups-moodle
això farà que ha diferents hores, a partir de les 4:30h comenci a fer backups només de les coses que s'han modificat.
formatejar unitat de disc
Formatejar una unitat de disc o memòria usb en linux es molt senzill
desmontar la unitat
on sdb1 correspon al nom de la teva unitat de disc
formatejem
#mkfs.ext3 /dev/sdb1
A la primera comanda formatejem en vfat, sobretot per usb's, i la segona comanda formatejem en ext3
creem un directori a l'arrel
mkdir /backups
mount -t ext3 /dev/sdb1 /backups
desmontar la unitat
# umount /dev/sdb1on sdb1 correspon al nom de la teva unitat de disc
formatejem
# mkfs.vfat /dev/sdb1#mkfs.ext3 /dev/sdb1
A la primera comanda formatejem en vfat, sobretot per usb's, i la segona comanda formatejem en ext3
creem un directori a l'arrel
mkdir /backups
mount -t ext3 /dev/sdb1 /backups
Autentificación por claves RSA/DSA - via ssh
Autentificación por claves RSA/DSA
Anem a configurar el servidor per accedir via ssh , mitjançant claus rsa/dsa i sense password de manera segura.
Al fitxer de configuració del servidor (on volem connectar-nos 192.168.130.x)
/etc/ssh/sshd_config
PubkeyAuthentication yes
En el client generem les claus DSA;
ssh-keygen -t dsa
podem posar un password pero si ho deixem em blanc la entrada serà directa
Per introduir aquesta ordre, al directori home/.ssh ens ha generat una clau publica i una privada. La clau pública la hem de copiar al servidor al directori de l'usuari amb el que connectarem
sftp root@192.168.130.x
put ./ssh/id_dsa.pub (hem copiat la clau publica de l'equip client al servidor)
en algún lloc indica que així també es pot fer pero no ho he comprobat
$scp archivo_local user@host:archivo_remoto
scp id_dsa.pub alvaro@intranet:.ssh/id_dsa.pub
The authenticity of host 'intranet (192.168.200.70)' can't be established. RSA key fingerprint is d8:d7:0a:cf:d9:8f:fe:fa:66:f0:76:46:46:fa:b8:1a. Are you sure you want to continue connecting (yes/no)?
El fingerprint és la firma digital del servidor. per establir una connexió la hem d'acceptar i demana una contrasenya, en aquest moment la copia la fitxer .ssh/know_host de la màquina local. Aquesta emprenta (firma) queda al fitxer de tal manera que si hi ha una connexió de la mateixa ip pero amb diferent firma ens dirà que no es pot establir la connexió. llavors hauriem d'esborrar l'entrada corresponent a aquella connexió al fitxer know_hosts (pero això ara no toca)
Ara connectem al servidor,fem los siguiente: cd /home/usuario/.ssh/
cat id_dsa.pub_CLIENTE >> authorized_keys
rm id_dsa.pub_CLIENTE
Ara ja podem connectar directament a l'ordinador remot sense tenir que introduïr el passwd, posarem
ssh usuari@192.168.130.x
i accedirem directament. Valorar que l'acces al directori ./ssh ha d'estar restringit només a nosaltres,
chmod 700 .ssh
Amb aquesta configuració ja puc llençar rsync sense tenir que posar el passwd.
Al tanto, l'accés a un ordinador ara ens està donant acces amb aquell usuari a altres ordinador sense password, s'ha de ser més segur....
Anem a configurar el servidor per accedir via ssh , mitjançant claus rsa/dsa i sense password de manera segura.
Al fitxer de configuració del servidor (on volem connectar-nos 192.168.130.x)
/etc/ssh/sshd_config
PubkeyAuthentication yes
En el client generem les claus DSA;
ssh-keygen -t dsa
podem posar un password pero si ho deixem em blanc la entrada serà directa
Per introduir aquesta ordre, al directori home/.ssh ens ha generat una clau publica i una privada. La clau pública la hem de copiar al servidor al directori de l'usuari amb el que connectarem
sftp root@192.168.130.x
put ./ssh/id_dsa.pub (hem copiat la clau publica de l'equip client al servidor)
en algún lloc indica que així també es pot fer pero no ho he comprobat
$scp archivo_local user@host:archivo_remoto
scp id_dsa.pub alvaro@intranet:.ssh/id_dsa.pub
The authenticity of host 'intranet (192.168.200.70)' can't be established. RSA key fingerprint is d8:d7:0a:cf:d9:8f:fe:fa:66:f0:76:46:46:fa:b8:1a. Are you sure you want to continue connecting (yes/no)?
El fingerprint és la firma digital del servidor. per establir una connexió la hem d'acceptar i demana una contrasenya, en aquest moment la copia la fitxer .ssh/know_host de la màquina local. Aquesta emprenta (firma) queda al fitxer de tal manera que si hi ha una connexió de la mateixa ip pero amb diferent firma ens dirà que no es pot establir la connexió. llavors hauriem d'esborrar l'entrada corresponent a aquella connexió al fitxer know_hosts (pero això ara no toca)
Ara connectem al servidor,fem los siguiente: cd /home/usuario/.ssh/
cat id_dsa.pub_CLIENTE >> authorized_keys
rm id_dsa.pub_CLIENTE
Ara ja podem connectar directament a l'ordinador remot sense tenir que introduïr el passwd, posarem
ssh usuari@192.168.130.x
i accedirem directament. Valorar que l'acces al directori ./ssh ha d'estar restringit només a nosaltres,
chmod 700 .ssh
Amb aquesta configuració ja puc llençar rsync sense tenir que posar el passwd.
Al tanto, l'accés a un ordinador ara ens està donant acces amb aquell usuari a altres ordinador sense password, s'ha de ser més segur....
diumenge, 7 de març del 2010
transferència de zones via dns
fer transferència de zones via dns es un error cada vegada ja menys comú donada la notificació d'aquesta incidència als servidors.
posarem les ordres per realitzar-ho mitjançant windows i linux
windows
D:\xarxes\NTSECURITY.NU>NSLOOKUP
Servidor predeterminado: google-public-dns-a.google.com
Address: 8.8.8.8
> SERVER LOZANO.NET
Servidor: LOZANO.NET
Address: 72.55.153.153
*** LOZANO.NET no se puede encontrar SERVER: Query refused
> server lozano.net
Servidor predeterminado: lozano.net
Address: 72.55.153.153
> set type-any
> ls -d lozano.net
[lozano.net]
lozano.net. SOA meteorico.com albert.lozano.net. (2009060
406 10800 3600 604800 600)
lozano.net. NS name.meteorico.com
lozano.net. NS name2.meteorico.com
lozano.net. A 72.55.153.153
lozano.net. MX 5 mail.lozano.net
lozano.net. MX 15 mailbackup.meteorico.com
casa A 80.26.53.225
fmtest A 80.26.53.225
ftp A 72.55.153.153
m A 72.55.153.153
mail A 72.55.153.153
www A 72.55.153.153
lozano.net. SOA meteorico.com albert.lozano.net. (2009060
406 10800 3600 604800 600)
>
AMB LINUX I AMB COMANDA DIG
dig @lozano.net lozano.net axfr
; <<>> DiG 9.5.1-P3 <<>> @lozano.net lozano.net axfr
; (1 server found)
;; global options: printcmd
lozano.net. 600 IN SOA meteorico.com. albert.lozano.net. 2009060406 10800 3600 604800 600
lozano.net. 600 IN NS name.meteorico.com.
lozano.net. 600 IN NS name2.meteorico.com.
lozano.net. 600 IN A 72.55.153.153
lozano.net. 600 IN MX 5 mail.lozano.net.
lozano.net. 600 IN MX 15 mailbackup.meteorico.com.
casa.lozano.net. 600 IN A 80.26.53.225
fmtest.lozano.net. 600 IN A 80.26.53.225
ftp.lozano.net. 600 IN A 72.55.153.153
m.lozano.net. 600 IN A 72.55.153.153
mail.lozano.net. 600 IN A 72.55.153.153
www.lozano.net. 600 IN A 72.55.153.153
lozano.net. 600 IN SOA meteorico.com. albert.lozano.net. 2009060406 10800 3600 604800 600
;; Query time: 177 msec
;; SERVER: 72.55.153.153#53(72.55.153.153)
;; WHEN: Sun Mar 7 21:29:47 2010
;; XFR size: 13 records (messages 1, bytes 341)
Ja he comentat que cada vegada és més difícil realitzar aquestes transferències de zona pero també es cert que si no funciona, es poden anar provant noms típics pels ordinador com inicials, a,b,c,.. els serveis que tenen, www,smtp,pop,www3,ftp.... per tal d'anar obtenint informació.
Y éste es el script (linux) que hace fuerza bruta sobre el servidor DNS:
dominio="dominio.com"
dns="dns1.dominio.com"
for nombre in `cat nombres.txt`
do
dig @$dns $nombre.$dominio grep -v ";" grep -v SOA grep $nombre.$dominio
done
posarem les ordres per realitzar-ho mitjançant windows i linux
windows
D:\xarxes\NTSECURITY.NU>NSLOOKUP
Servidor predeterminado: google-public-dns-a.google.com
Address: 8.8.8.8
> SERVER LOZANO.NET
Servidor: LOZANO.NET
Address: 72.55.153.153
*** LOZANO.NET no se puede encontrar SERVER: Query refused
> server lozano.net
Servidor predeterminado: lozano.net
Address: 72.55.153.153
> set type-any
> ls -d lozano.net
[lozano.net]
lozano.net. SOA meteorico.com albert.lozano.net. (2009060
406 10800 3600 604800 600)
lozano.net. NS name.meteorico.com
lozano.net. NS name2.meteorico.com
lozano.net. A 72.55.153.153
lozano.net. MX 5 mail.lozano.net
lozano.net. MX 15 mailbackup.meteorico.com
casa A 80.26.53.225
fmtest A 80.26.53.225
ftp A 72.55.153.153
m A 72.55.153.153
mail A 72.55.153.153
www A 72.55.153.153
lozano.net. SOA meteorico.com albert.lozano.net. (2009060
406 10800 3600 604800 600)
>
AMB LINUX I AMB COMANDA DIG
dig @lozano.net lozano.net axfr
; <<>> DiG 9.5.1-P3 <<>> @lozano.net lozano.net axfr
; (1 server found)
;; global options: printcmd
lozano.net. 600 IN SOA meteorico.com. albert.lozano.net. 2009060406 10800 3600 604800 600
lozano.net. 600 IN NS name.meteorico.com.
lozano.net. 600 IN NS name2.meteorico.com.
lozano.net. 600 IN A 72.55.153.153
lozano.net. 600 IN MX 5 mail.lozano.net.
lozano.net. 600 IN MX 15 mailbackup.meteorico.com.
casa.lozano.net. 600 IN A 80.26.53.225
fmtest.lozano.net. 600 IN A 80.26.53.225
ftp.lozano.net. 600 IN A 72.55.153.153
m.lozano.net. 600 IN A 72.55.153.153
mail.lozano.net. 600 IN A 72.55.153.153
www.lozano.net. 600 IN A 72.55.153.153
lozano.net. 600 IN SOA meteorico.com. albert.lozano.net. 2009060406 10800 3600 604800 600
;; Query time: 177 msec
;; SERVER: 72.55.153.153#53(72.55.153.153)
;; WHEN: Sun Mar 7 21:29:47 2010
;; XFR size: 13 records (messages 1, bytes 341)
Ja he comentat que cada vegada és més difícil realitzar aquestes transferències de zona pero també es cert que si no funciona, es poden anar provant noms típics pels ordinador com inicials, a,b,c,.. els serveis que tenen, www,smtp,pop,www3,ftp.... per tal d'anar obtenint informació.
Y éste es el script (linux) que hace fuerza bruta sobre el servidor DNS:
dominio="dominio.com"
dns="dns1.dominio.com"
for nombre in `cat nombres.txt`
do
dig @$dns $nombre.$dominio grep -v ";" grep -v SOA grep $nombre.$dominio
done
divendres, 5 de març del 2010
signatura de clau publica que no es pot verificar en l'actualització debian
ja portava un temps que em sortia un error que no acabava de resoldre sobre que no té correcta la clau publica d'un repositori de debian, potser ja havia caducat.
jo faig l'actualització mitjançant apt-get update i apt-get upgrade. A la verificació dels paquets de Debian utilitza una clau digital per assegurar que el paquets pertany a debian, per aquesta raó fa un d'un certificat que sembla ser que es renova anualment.
Recientemente, al hacer un "aptitude update" aparecía un error al acceder a uno de los repositorios. El error que aparecía era el siguiente:
W: GPG error: http://packages.freecontrib.org dapper Release: Las firmas siguientes no se pudieron verificar porque su llave pública no está disponible: NO_PUBKEY 9AA38D55BE302B
en el meu cas i validat al sistema com root he posat:
gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 9AA38D55BE302B
gpg --armor --export 9AA38D55BE302B |apt-key add -
---------
jo faig l'actualització mitjançant apt-get update i apt-get upgrade. A la verificació dels paquets de Debian utilitza una clau digital per assegurar que el paquets pertany a debian, per aquesta raó fa un d'un certificat que sembla ser que es renova anualment.
Recientemente, al hacer un "aptitude update" aparecía un error al acceder a uno de los repositorios. El error que aparecía era el siguiente:
W: GPG error: http://packages.freecontrib.org dapper Release: Las firmas siguientes no se pudieron verificar porque su llave pública no está disponible: NO_PUBKEY 9AA38D55BE302B
en el meu cas i validat al sistema com root he posat:
gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 9AA38D55BE302B
gpg --armor --export 9AA38D55BE302B |apt-key add -
---------
dimarts, 2 de març del 2010
Sincronització hora a linux via ntp
A veure, els alumnes s'han queixat que el servidor on penja el moodle va un parell de minuts avançat, i per una altre banda, el servidor d'oracle resulta que estava sis hores retrasat. Solució, sincronitzar al el servidor de temps que tenim al centre pero que podia ser qualsevol màquina.
Donat que els servidors son debian hem d'instal·lar ntp i ntpdate
ntpdate -u 2.pool.ntp.org
per sincronitzar-ho en hora amb servidors d'internet publics que apareix a ntp.org
Fet.
Ara aprofito i connecto al servidor d'opensuse per fer el mateix procediment, servidor de referència horaria per provar en una altra distribució, poso la comanda ntpdate .... i em contesta que no ha de ser aquesta la comanda.
servidor:~ # ntpdate -u 2.pool.ntp.org
!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!!
The ntpdate program is deprecated and should not be used any more. To
quote the upstream ntp developers:
"The functionality ntpdate offered is now provided by the ntpd daemon
itself. If you call ntpd with the command line option -q it will
retrieve the current time and set it accordingly."
Please check the Network Time Protocol (NTP) daemon man page and
http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
for further information.
You can replace the ntpdate call with "rcntp ntptimeset" to achieve an
inital poll of the servers specified in /etc/ntp.conf.
The program /usr/sbin/sntp offers comparable functionality to ntpdate.
Specifically
sntp -P no -r pool.ntp.org
is equivalent to
ntpdate pool.ntp.org
Llavors he fet
sntp -P no -r europe.pool.ntp.org
per opensuse
Donat que els servidors son debian hem d'instal·lar ntp i ntpdate
apt-get install ntp ntpdate
per sincronitzar-ho en hora amb servidors d'internet publics que apareix a ntp.org
Fet.
Ara aprofito i connecto al servidor d'opensuse per fer el mateix procediment, servidor de referència horaria per provar en una altra distribució, poso la comanda ntpdate .... i em contesta que no ha de ser aquesta la comanda.
servidor:~ # ntpdate -u 2.pool.ntp.org
!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!!
The ntpdate program is deprecated and should not be used any more. To
quote the upstream ntp developers:
"The functionality ntpdate offered is now provided by the ntpd daemon
itself. If you call ntpd with the command line option -q it will
retrieve the current time and set it accordingly."
Please check the Network Time Protocol (NTP) daemon man page and
http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
for further information.
You can replace the ntpdate call with "rcntp ntptimeset" to achieve an
inital poll of the servers specified in /etc/ntp.conf.
The program /usr/sbin/sntp offers comparable functionality to ntpdate.
Specifically
sntp -P no -r pool.ntp.org
is equivalent to
ntpdate pool.ntp.org
Llavors he fet
sntp -P no -r europe.pool.ntp.org
per opensuse
Subscriure's a:
Missatges (Atom)
Entrades
