Doppio pinguino per l'avvio di Knoppix su un pc con processore dual-core.
Viene da pensare ovviamente, però mi ha colpito!

Questo pomeriggio il server che ospita garinci è stato vittima di un ddos . Decisamente poco divertente.
Le barre verdi sono il traffico in ingresso, solo 400 volte superiore al normale.

Ho dovuto ricreare la home del mio account su Suse 10.2. Tra i vari problemi che si sono presentati alla ripartenza, uno particolarmente noioso, è stato che k3b non vedeva alcun masterizzatore. Questo problema lo avevo anche con Suse 10.0, ma lì per mancanza di tempo ho risolto facendo fare a root le masterizzazioni.
Nel caso di Suse 10.2, mi sono puntato ed ho trovato una soluzione sufficientemente elegante:

il masterizzatore fa riferimento al file
brw-r----+ 1 root disk 22, 0 11 gen 10:11 /dev/hdc
che, come si vede, ha i permessi in lettura e scrittura per root e solo in lettura per il gruppo disk.

E' bastato quindi modificare i permessi in questo modo
brw-rw----+ 1 root disk 22, 0 11 gen 10:11 /dev/hdc
ed aggiungere il mio account al gruppo disk.

In questo modo k3b ha riconosciuto correttamente ed autonomamente il masterizzatore.

I cattivi rapporti tra Suse ed i touchpad Alps sono ormai un fatto consolidato dal tempo. Neanche l'ultima versione, la 10.2, riesce a risolvere questo problema.

Il rimedio è sempre lo stesso che adotto da Suse 9.2, ossia aggiungere una voce nella riga delle opzioni del kernel nel file /boot/grub/menu.lst

kernel /boot/vmlinuz root=/dev/hda6 vga=0x317 resume=/dev/hda5 splash=silent
showopts psmouse.proto=bare

In questo modo si disabilita la patch aggiunta dai tecnici Suse che crea problemi.

Tutto queste informazioni le ho reperite su suseitalia.org
http://www.suseitalia.org/modules/wfsection/article.php?page=1&articleid=34

Ho aggiornato il server di pre-produzione all'ultima release SUSE, la 10.1.
E' stata un'operazione semplice e pulita come mi aspettavo.

Il server in questione, aveva installata la SUSE 10.0 con diversi servizi attivi:

Apache
MySQL
SVN
NFS
SAMBA
CUPS

Tutti i software sono stati aggiornati all'ultima versione e al riavvio sono ripartiti senza intoppi e senza aver perso un dato.
La procedura che ho seguito è stata molto semplice: ho fatto fare tutto al software d'installazione! Ho accettato qualunque suggerimento e facilitazione proposti, facendo aggiornare tutti i pacchetti durante l'installazione con tutte le patch disponibili e riservandomi di intervenire a mano a posteriori. L'accorgimento di eseguire l'aggiornamento durante l'installazione mi ha fatto evitare i noti problemi con il nuovo software d'aggiornamento pacchetti adottato (Zen).
Le uniche "difficoltà" hanno riguardato alcuni script php che hanno dovuto essere sistemati per adattarsi alla nuova versione di Apache (1.3 -> 2.0) e di PHP (4->5).

In breve, dopo circa 2 ore, il server è ripartito con una nuova e scintillante SUSE 10.1

Dopo un intenso lavoro di documentazione,

http://www.netfilter.org/documentation/index.html
http://assistenza.seflow.net/forum/viewtopic.php?t=43
http://www.siliconvalleyccie.com/linux-hn/iptables-intro.htm
http://easyfwgen.morizot.net/
http://www.iptablesrocks.org/
http://www.faqs.org/docs/securing/gen-syssecured.html
http://www.faqs.org/docs/iptables/
http://www.datasecurity.it/top20/

sono arrivato alla definizione delle regole per il firewall del server.

Tutte le fatiche sono raccolte qui
http://assistenza.seflow.net/forum/viewtopic.php?t=171 

La cronica lentezza dei dns del mio provider, ma sopratutto la svolta estremista che ha colpito gli ISP italiani mi ha spinto ad organizzarmi per avere un servizio dns più efficace e che non dice "fesserie".

Naturalmente avevo già implementato un cache dns sul mio computer, quindi mi è bastato trovare dei dns server veloci e non soggetti alla legislazione italiana.

ORSN Open Root Server Network è una rete di root-dns ,alternativa a quella gestita da ICANN, con base in Europa. Le istruzione per implementare il servizio sono disponibili a questo indirizzo http://european.ch.orsn.net/tech-switch.php

Dovendo installare un pc senza lettore cd , non potendo aprire il case per fare un collegamento volante via bus eide, non avendo un lettore esterno usb o firewire, ho risolto effettuando il boot da una pennina usb e facendo partire l'installer da lì.

Continua "Installare Suse 10.0 da penna usb"

​​​​Ho aggiornato il server casalingo da Suse 9.0 a Suse 10.0; l'operazione è andata sufficientemente bene, tranne che per tre problemini.
Uno dei tre è il seguente:
/usr/X11R6/bin/xauth:  error in locking authority file /home/gmcr/.Xauthority

Non sono ancora riuscito a capire chi sia il responsabile, ma semplicemente il file .Xauthority non viene cancellato al logout e  diventa di proprietà di root. Conseguentemente ai successivi login il file non è accessibile e quindi non può prendere il nuovo MIT-MAGIC-COOKIE, che viene generato ad ogni login.
In definitiva non riesco a fare il Forward X sul computer dal quale  effettuo il login >:-\

Patch provvisoria
ho aggiunto al file ~/.bash_logout, il comando per cancellare il file .Xauthority

$ rm -f .Xauthority* >> ~/.bash_logout

In attesa di capire chi non compie il suo dovere sino in fondo, funziona.

Letta su Gulchelp.

La discussione cercava di individuare un buon modo per tenere traccia dell'attività di uno script e contemporaneamente sganciare l'esecuzione del suddetto script dalla shell. Il risultato, molto istruttivo, è di Bronto:

"( mioscript.sh < /dev/null > file.log 2>&1 & )

Col "< /dev/null" gli dici di prendere input da /dev/null (non prendera`
una seppia, ma quantomeno ti libera il device tty/pty, sempre che stia
cercando di usarlo).

Col "> file.log" redirigi l'output dello script sul file file.log nella
directory corrente.

Con 2>&1 redirigi lo standard error sullo standard output, che essendo
stato precedentemente rediretto sul file.log andra` anche'esso a finire li`.

Col "&" lo mandi in background

Con le parentesi, il comando viene lanciato in una subshell, e questo ti
libera la shell iniziale."

Credo che anche nohup, al posto delle parentesi tonde, abbia lo stesso effetto.

E' mancata la luce mentre il pc faceva il boot; risultato -> qualche file fregato e avvio impossibile. Grub parte ma si ferma dopo qualche istante senza concludere niente, presentando la shell di comando.

Continua "Boot a mano"

Utilizzando Eclipse 3.0 con workspace appoggiato su una directory nfs, ottenevo un errore di "risorsa in uso" e il programma rifiutava di avviarsi.
Dalla mailing list di Eclipse ho appreso che è un problema del Java lock mechanism che non funziona correttamente con questo filesystem; per ovviare all'incoveniente ho avviato Eclipse con il seguente parametro aggiuntivo: -vmargs -Dosgi.locking=java.io
Funziona (per me ;-).

Stimolato dall'articolo di Paolo Attivissimo su Apogeonline.com, propongo la mia personale ricetta per un "Personal Local Gmail".
Continua "Personal Local Gmail"