Giuseppe Del Duca Just Me, my Life, my Work, Myself…

Nonostante tutte le accortezze, può capitare talvolta di trovarsi il server bucato da qualcuno che non ha niente di meglio da fare nella vita. Premesso che per sicurezza sarebbe sempre meglio una reinstallazione completa del sistema, potrebbe essere necessario “mantenere in vita” la macchina per compiere alcune operazioni o semplicemente salvare i dati. Purtroppo alcuni rootkit (es. SHV4 e SHV5 su linux ubuntu 8.04) hanno la brutta abitudine di patchare e modificare i permessi di alcuni file (/bin/ls /bin/netstat /bin/ps /bin/top ecc…), per cui quando si tenta di ripristinarli ci si trova un bel “Operation not permitted” perchè li hanno impostati come “immutabili”. Quindi, dopo una buona dose di imprecazioni, ecco come fare per controllare i permessi usando il nostro amico lsattr:

# lsattr /bin/ls
s—ia——- ./ls
# lsattr /bin/ps
s—ia——- ./ps
# lsattr /bin/netstat
s—ia——- ./netstat

…e soprattutto la soluzione:

# chattr -sia /bin/ls
# chattr -sia /bin/ps
# chattr -sia /bin/netstat

E per finire… un bel dito medio a tutti gli sviluppatori di rootkit!

Giusto un paio di note a titolo di promemoria su come controllare a chi spedire i report dei cronjob (oppure come evitare che cron spedisca le email). Di default cron spedisce la mail all’utente proprietario del cronjob (configurare la mail in /etc/aliases).

Aprire la lista dei cronjobs:

$ crontab -e

Per impostare il destinatario dei report di cron:

MAILTO=test@foobar.com

Se non voglio che venga spedita alcuna email:

MAILTO=""

Per evitare la mail di alcuni cronjob, impostare come segue:

* * * * * /path/to/command >/dev/null 2>&1 

Eventualmente togliere il 2>&1 se vogliamo spedire solo gli errori.

Ho appena scoperto un bug molto fastidioso di php5-cli. In pratica: se si crea uno script php, eseguito da shell chiamato da cron, e nel file di configurazione php.ini è stato attivato il supporto per php_gtk, il relativo cronjob fallisce. La cosa strana è che se lo stesso script viene eseguito lanciandolo a mano da shell, funziona senza alcun problema. Assurdo, vero? Non so quale sia la causa, ma purtroppo quando voglio sviluppare con le gtk, bisogna sospendere i cronjob che interessano il php.

Bah… chissà che qualcuno lo risolva presto… o forse come spesso accade, sono l’unico che ha questi problemi? 

Did you get a black screen or “out of range” message? Here it is the solution:

sudo apt-get remove grub
sudo apt-get install grub-pc
sudo grub-install /dev/sda
sudo update-grub2

After running that last command, you should see your linux and windows install listed in the terminal output. Next, we try to fix your splash problem (and hopefully it speeds up your boot):

sudo apt-get install v86d
gksu gedit /etc/default/grub

Look for the line that says:
GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash”
and replace it with: Leggi il resto di questo articolo »

Suppongo che molti di voi, come me, si siano trovati spiazzati con la nuova configurazione di Grub2. La cosa probabilmente più utile per chi lavora da shell, è poter impostare la risoluzione più alta in grub2. Nel vecchio grub c’era il parametro vga da passare al kernel, mentre per cambiare la risoluzione di grub2 bisogna:

Aprire il file /etc/default/grub

Modificare (o aggiungere) i seguenti parametri

GRUB_GFXMODE=1024x768
GRUB_GFXPAYLOAD_LINUX=keep

Salvare il file e dare questi comandi da shell:

sudo grub-mkconfig && update-grub

Fatto!

(Grub2 help: https://help.ubuntu.com/community/Grub2)