Come ho già scritto nel blog in passato, noi ci occupiamo anche di callcenter e le nostre centrali Asterisk sono basate su di un framework in Java e PHP (vecchio core, adesso rilegato a scopi minori).
Comunque la parte in PHP è molto stressata, come fosse un sito da alto traffico, quindi il carico nella CPU normalmente sale molto, quindi da anni usiamo eAccelerator, come dice il nome ottimizza ed accelera il PHP, cachando il compilato.
Però cercando di compilarlo come estensione Zend in un nostro server, durante il make ricevevo un errore
eaccelerator-0.9.6.1/ea_store.c: In function ‘store_property_access_check’:
eaccelerator-0.9.6.1/ea_store.c:683: error: ‘zend_property_info’ has no member named ‘ce’
make: *** [ea_store.lo] Error 1
In questo caso va editato il file ea_store.c ed alla linea 653 dobbiamo commentare (quindi //) la linea return (child_info->ce != from);
A questo punto salvare e tentare di nuovo la compilazione, che si concluderà senza problemi.
Ho creato uno script molto semplice per ricavare l’ip della eth0.
Mi serviva per il bind del JBoss, in uno script che doveva essere eseguito su diverse macchine, di cui ovviamente non potevo conoscere a priori l’ip.
Il semplice script
ifconfig | grep ‘inet addr:’| grep -v ’127.0.0.1′ |
cut -d: -f2 | awk ‘{ print $1}’
Può essere utile eliminare le varie cartelle .svn all’interno delle cartelle di lavoro, nel caso ad esempio volessimo spostare/aggiornare queste stesse cartelle in un altro repository, ma come farlo senza farlo a mano?
Semplicemente così
find / -name .svn -print0 | xargs -0 rm -rf
That’s all folks!
Di recente mi è capitato d’installare un server IBM x3650 con Ubuntu 8.04 ed ovviamente una delle necessità è stata quella di monitorare lo stato del raid attraverso il software di corredo by IBM, ovvero Raid Manager, però qui cominciano i problemi.
Come quasi tutto il software “brand”, sono forniti solo gli rpm, quindi dobbiamo armarci di alcuni pacchetti (e pazienza) per risolvere la cosa.
Innanzittutto dobbiamo installare rpm
# sudo apt-get install rpm
dopo di chie alcune librerie, ovvero
# sudo apt-get install libstdc++5 libstdc++5-3.3-dev
Scompattermo l’rpm fornito nel cd dell’IBM (potrete anche avere la versione 9, nei server recenti)
# cd /var/tmp
# rpm2cpio RaidMan-8.40.i368.rpm | cpio -dimv
Sarà creata una directory chiamata /var/tmp/usr/RaidMan, quindi muoviamo RaidMan in /usr e quindi decomprimiamo il JRE fornito con il pacchetto, oppure potete usarlo uno a piacimento, in tal caso dovrete avere un link simbolico “jre” nella directory /usr/RaidMan che punti al “vostro” jre.
# cd /usr/RaidMan
# tar xfvz sun-jre142linux32.tgz
infine copieremo in init.d, renderemo avviabile e setteremo che parta al boot lo script di avvio dell’agente del raid manager
# cp /usr/RaidMan/raid_agent /etc/init.d/
# chmod +x /etc/init.d/raid_agent
# update-rc.d raid_agent defaults
e alla fine lo avvieremo e non dovrebbe dare errori di sorta
# /etc/init.d/raid_agent start
starting IBM ServeRAID Manager agent …
Adesso dato che la Ubuntu Server 8.04 non ha una GUI, installeremo lo stesso programma su di un pc Windows ed aggiungeremo il sistema remoto che dovrebbe rispondere e far vedere lo stato del raid senza problemi.
Allora qui il fatto è il più complesso, infatti io nel mio dns aziendale utilizzo 3 view, una per la lan, una per l’esterno e una per le vpn:
Quadno veniva fatto lo zone transfer, però passava solo una zona, o meglio sul server secondario venivano si passati 3 file, ma idendici! (la zona internal).
La soluzione è avere un indirizzo ip sul secondario per ogni zona da trasferire, si lo so è un pò vago ma una soluzione dettagliata la trovate qui, ora non ho tanta voglia di scrivere (sono impegnato da facebook!
)
Oramai qualsiasi server che faccio è “made Ubuntu”, però questa cosa mi ha dato del filo da torcere!
Praticamente quando effettuavo il classico zone transfer, mi veniva restituito un errore del tipo dumping master file: tmp-5L67ipnxc9: open: permission denied però mi è parso subito strano, perchè la cartella sotto /etc/bind/slave era di proprietà di Bind e con i giusti permessi! Doh!
Pare leggendo sui forum che sia dovuto a qualche non meglio precisato errore sull’assegnazione dei permessi…mha… non ho indagato più di tanto.
Fa sta che ho settato come directory per ospitare i file la dir /var/cache/bind ed il trasferimento di zona è bello e servito!
Stavo migrando alcuni dei miei server Ubuntu 8.04 da VMware Server 1.0.6 ad ESX 3.5 con l’apposito VMware converter, fino a qua tutto ok, finita la migrazione faccio la ripartire la macchina, aggiorno i tools e…argh!!!
Dove sono le schede di rete?? Ripartendo le macchine, anche con i drivers vmxnet corretti non vogliono sapere di andare su…poi mi sono ricordato di lui…udev!
Infatti per evitare che ad ogni riavvio il nome delle schede di rete sia scelto a caso, udev si annota i mac address delle schede di rete, assegnando i rispettivi MAC a eth0, eth1 e così via.
Ovviamente nel nuovo ESX server ci saranno mac diversi, quindi dovremmo cancellare questa info, per fare questo cancellate qui
sudo rm /etc/udev/rules.d/70-persistent-net.rules
Dopo un restart dovreste trovarvi con le interfacce attive.
Non sono sparito eh!
Ma in questo periodo sto lavorando anche la sera alla ristrutturazione interna della nostra azienda, con il rifacimento dei server, della rete….insomma una cosa radicale!
Abbiamo anche studiato soluzioni nuove (almeno per noi!), ecco un piccolo elenco:
Quindi con tutto questo mi rimane poco tempo!
Quando vi troverete a preparare i certificati per OpenVPN con Windows(easy-rsa) potrete incappare in un piccolo problema, non esiste più lo script per permette di assegnare una password al certificato.
Questo script si chiamava build-key-pass.bat e permetteva di associare una password al PKI, in modo che per collegarsi con OpenVPN sia necessario anche digitare una password (magari in caso di furto del laptop!)
Comunque sia prendete lo script build-key.bat, editatelo e cancellate l’opzione -nodes.
In questo modo quando lancerete lo script vi verrà anche chiesta una password PEM, che al momento della connessione sarà richiesta.
Allora premetto che questo aggiornamento è vitale se avete il PHP 5.2.2, perchè rischiate di avere il server bucato (successo di già), quindi è vitale!
Il problema è che tramite yum e i classici repository questo non è possibile (e non capisco perchè):
Comunque sia per risolvere useremo un repo adhoc, fate questo
wget -q -O – http://www.atomicorp.com/installers/atomic |sh
yum update php
E fatto questo, se tutto si installa per bene, riavviate Apache e se fate php -v dovrebbe restituirvi una versione superiore o uguale a 5.2.6

Categories
Tag Cloud
Blog RSS
Comments RSS
Last 50 Posts
Back
Void « Default
Life
Earth
Wind
Water
Fire
Light 