LDAP SSO on Linux – Used for GLPI

Note to myself:

apache-logo

# This configuration file allows the manual to be accessed at
# http://localhost/manual/
#
#Loglevel debug
KeepAlive On

Alias /glpi “/var/www/glpi”

<Directory “/var/www/glpi”>

PerlAuthenHandler Apache2::AuthenNTLM
AuthType ntlm,basic
AuthName Access
require valid-user
PerlAddVar ntdomain “DOMAIN PDO  BDO”
PerlSetVar defaultdomain DOMAIN
PerlSetVar splitdomainprefix 1
PerlSetVar ntlmdebug 0
PerlSetVar ntlmauthoritative off

# Uncomment following to force use of HTTPS in Administration Server

#SSLRequireSSL

# PHP tuning (not working on all distribution, use php.ini instead)
AddType application/x-httpd-php .php
php_flag file_uploads on
# Some PHP tuning for deployement feature up to 8 MB
# post_max_size must be greater than upload_max_filesize
# because of HTTP headers
php_value post_max_size 9m
php_value upload_max_filesize 8m
# You may have to uncomment following on errors
#php_value max_execution_time -1
#php_value max_input_time -1

# Uncomment following to allow HTTP body request up to 4 MB
# instead default 512 KB
#LimitRequestBody 4194304

</Directory>

Install Apache2::AuthenNTLM Perl module. In Debian just type:

aptitude install libapache2-authenntlm-perl

Remember to enable ntlm authentication on Windows machines. Not all versions (xp does), have it enabled.

Libnodave on Linux 64 bit

Note to myself.

Put these lines in the Makefile and then run “make”:

CFLAGS=-m64 -Wall -Winline -DLINUX -DDAVE_LITTLE_ENDIAN -fPIC
CTFLAGS=-m64 -Wall -Winline -fPID -DLINUX -DDAVE_LITTLE_ENDIAN -fPIC
CPPFLAGS=-m64 -Wall -Winline -DLINUX -DDAVE_LITTLE_ENDIAN -fPIC

Then:

cp libnodave.so  /usr/lib64/

cp nodave.h /usr/include

ldconfig

 

 

“GNU GRUB version 1.97″beta 4 [ Minimal BASH-

Today I was updating an Ubuntu 9.04 virtual machine to 12.04. I went successfully to the 10.04 but after the 11.10 upgrade, at the reboot I had the following message:

“GNU GRUB version 1.97″beta 4 [ Minimal BASH-like line editing is supported.For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device/file completions]

sh:grub>

Awkward! Couple of Google queries and I ran into help.ubuntu.com, where I found this pretty nice solution:

ls
set prefix=(hd0,1)/boot/grub
set root=(hd0,1)
set
ls /boot
insmod /boot/grub/linux.mod
linux /vmlinuz root=/dev/sda1
initrd /initrd.img
boot

Give this commands on Grub command line and keep in mind that I’m using sda1 (sda=hd0 | partition=1) and both /root and /boot are on the same partition.

As the system boots, login and issue the following command as root:

grub-install /dev/sda
update-grub

Then reboot. The system should boot up fine now!

Giochiamo con Label e UUID

Mettiamo il caso che si stia lavorando su un server, un lavoro delicato, eh, e che la fuckup fairy decida proprio in quel momento di venire a trovarvi…

Mettiamo il caso che per una botta incredibile di fortuna, vi interrompano mentre state eseguendo un echo su /etc/fstab e invece di un bel >> vi ritroviate con >.

Ok, in questo caso fate ciao ciao con la manina a /etc/fstab e pensate intensamente al fatto che, genialmente, chi si occupa dei backup se n’è andato in vacanza una settimana prima di voi.

Ora, proprio per non rendere le cose facili, tenete conto che il vostro /etc/fstab monti i filesystem indicandoli con una volume label che, ovviamente, ora non ricordate, del tipo :

LABEL=SW-cciss/c0d0p2   swap                    swap    defaults        0 0

Questo è un caso classico, una swap referenziata da label, e cancellata la riga chi si ricorda più dove, come, quando, perché? Volendo ripristinare un mount via label, una via semplice per recuperare l’etichetta mancante consiste nell’utilizzare bklid:

#: blkid /dev/cciss/c0d0p2
/dev/cciss/c0d0p2: TYPE="swap" LABEL="SW-cciss/c0d0p2" UUID="1b2e35d0-8321-4d5b-bed0-647b862cbc88"

Fatto. La label è

SW-cciss/c0d0p2

Incidentalmente, ma nemmeno troppo, blkid vi mostra anche la UUID del filesystem. Infatti, potreste volere montare il filesystem usando il suo UUID e quindi la precedente istruzione in /etc/fstab potrebbe essere riscritta come:

UUID=1b2e35d0-8321-4d5b-bed0-647b862cbc88 swap swap defaults 0 0

Ciò vale per qualsiasi filesystem. Per esempio, questa regola di mount per il filesystem contenente i database di MySQL, da così

/dev/VolGroup00/LogVol03 /var/lib/mysql ext3 defaults 1 2

passando per

#: blkid /dev/VolGroup00/LogVol03
/dev/VolGroup00/LogVol03: UUID="fb5050a9-6641-4ec8-a1dc-5365b326d9bd" TYPE="ext3"

Può essere riscritta come:

UUID=fb5050a9-6641-4ec8-a1dc-5365b326d9bd /var/lib/mysql ext3 defaults 1 2

Avete notato nulla? Il filesystem è sprovvisto di una volume label. Rimediamo applicando una etichetta che ci consenta di capire al volo la funzione del filesystem montato:

tune2fs -L "MySQL DB" /dev/VolGroup00/LogVol03

Controlliamo che il filesystem abbia preso l’etichetta in maniera corretta:


#: blkid /dev/VolGroup00/LogVol03
/dev/VolGroup00/LogVol03: UUID="fb5050a9-6641-4ec8-a1dc-5365b326d9bd" TYPE="ext3" LABEL="MySQL DB"

Ora non rimane che modificare /etc/fstab per rimontare il filesystem usando la nuova label:

LABEL=MySQL\040DB /var/lib/mysql ext3 defaults 1 2

Notato qualcosa? Forse quello

\040

messo fra MySQL e DB? Esatto. Serve per eseguire l’escape dello spazio fra le due parole che compongono la label. Se date un’occhiata al man 5 di fstab noterete che gli spazi vanno sottoposti a escape se si trovano all’interno di una etichetta o nel percorso del mount point. Quindi, corollario molto semplice, potete anche creare dei mount point il cui percorso sia composto da più termni separati da uno spazio.

Proviamoci:

mkdir "/Spazio per i file database di MySQL"

Quindi modifichiamo in questo modo /etc/fstab:

LABEL=MySQL\040DB /Spazio\040per\040i\040file\040database\040di\040MySQL ext3 defaults 1 2

Ora non rimane che smontare e rimontare il filesystem:

umount /var/lib/mysql/ ; mount -a

e infine, verifichiamo la buona riuscita dell’operazione:

#: mount | grep Spazio
/dev/mapper/VolGroup00-LogVol03 on /Spazio per i file database di MySQL type ext3 (rw)

e poi:

ls /Spazio\ per\ i\ file\ database\ di\ MySQL/
controllo ib_logfile0 ib_logfile1 ibdata1 lost+found mysql nagios_data

Bene, direi che tutto è a posto. Non vi rimane che fare qualche esperimento, giusto?

P.S.

Nel caso aveste giocato con la directory dei db di MySQL (ma siete pazzi come me?), rimettete tutto a posto, oppure modificate il puntamento in my.cnf.