Archives

Situație neplăcută după ceva upgrade de Ubuntu legată de /etc/init.d/screen-cleanup

S-a întâmplat moment de upgrade la ceva servere de la versiuni mai vechi de Ubuntu… și au apărut și primele situații neplăcute.

Din categoria “Note to self” ca să mă romglezesc corespunzător, în cazul în care mă mai lovesc de următoarea situație:

initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
insserv: warning: script 'screen-cleanup' missing LSB tags and overrides
insserv: Default-Start undefined, assuming empty start runlevel(s) for script `screen-cleanup'
insserv: Default-Stop undefined, assuming empty stop runlevel(s) for script `screen-cleanup'

Soluția este:

sudo mv /etc/init.d/screen-cleanup.dpkg-new /etc/init.d/screen-cleanup

După asta trebuie reactivate serviciile care nu mai voiau să pornească automat din cauza “ororii” de mai sus.

“Spargerea” unui fișier pdf cu pdftk

Birocrația noastră e încă în floare, iară companiile chiar private nu fac excepții de la comunicarea pseudo-electronică – îți trimit email cu contractele în format electronic dar nu-l acceptă înapoi decât semnat și ștampilat (eventual pe fiecare pagină) și “cu pix albastru”…
Ideea este că printr-un astfel de proces, după scanare un contract care ar fi fost un pdf de 500kb în formatul său inițial, poate ajunge la 15-20Mb după ce a fost printat, semnat și scanat din nou.
Iar cum sunt puține serverele de email care acceptă fișiere mari atașate emailurilor… apare aici distracția.
Astăzi am fost exact într-o astfel de situație, fișierul care trebuia “întors” avea mai bine de 15Mb.
Așa că am apelat la pdftk (PDF Toolkit) aplicație care este conform denumirii dată de cei care o întrețin “Handy Tool for Manipulating PDF Documents” și cu ajutorul căreia se pot face o mulțime de operații cu fișierele pdf, cum ar fi:
– Concatenarea sau colaj de documente pdf;
– Spargerea în fișiere cu număr definit de pagini
– Rotirea documentelor sau doa a numitor pagini dintr-un fișier pdf
– Decriptarea documentelor pdf (dacă știm parola)
– Criptarea fișierelor pdf
și multe alte operațiuni.

Dar cum tema de azi a fost spargerea în fișiere mai mici… iată cum se produce:
În primul rând se instalează pdftk:

alex@alex:~$ sudo apt-get update
alex@alex:~$ sudo apt-get install pdftk

Iar apoi am generat 3 fișiere mai mici din fișierul inițial după cum urmează:

alex@alex:~$ pdftk initial.pdf cat 1-5 output output_split1-5.pdf
alex@alex:~$ pdftk initial.pdf cat 6-10 output output_split6-10.pdf
alex@alex:~$ pdftk initial.pdf cat 11-15 output output_split11-15.pdf

Iar la final am avut 3 fișiere cu câte 5 pagini și dimensiune sub 7Mb dintr-un singur fișier care avea mai mult de 15Mb.

Pentru lista completă de operatori și exemple rulați cu încredere

alex@alex:~$ pdftk --help

pdftk

Apache 2.4 mod_remoteip pentru colectarea în loguri a ip-urilor reale

Într-unul din proiectele recente am avut de pus pe picioare un setup în AWS.
Una dintre problemele pe care nu le anticipasem a fost că ip-urile vizitatorilordin logurile Apache erau suprascrise cu cel al load balancer-ului.

Căutând soluții am ales ceea ce mi s-a părut a fi cea mai simplă abordare și care satisface cerința fără multe modificări și anume folosirea modulului mod_remoteip din Apache 2.4.x

Pentru asta (serverele rulând Ubuntu) pașii sunt următorii:

$ sudo a2enmod mod_remoteip

Apoi în fișierul /etc/apache2/mods-enabled/remoteip.conf sau direct în /etc/apache2/apache2.conf (după dorința fiecăruia) se adaugă:

 RemoteIPHeader X-Forwarded-For

iar în secțiunea de definire a metodelor de log din /etc/apache2/apache2.conf se schimbă:

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined

în

LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined

Adicătălea din %h în %a.

La final se restartează serverul de apache și din acest moment în loguri ar trebui să apară ip-urile reale ale vizitatorilor.

VMWare Player 7.x pe Ubuntu 15.04 – telenovela continuă

Se întâmplă destul de des în ultima vreme să văd cum reapar probleme cu funcționarea unor aplicații mai ales după actualizări, mai mici sau mai mari.
Una din problemele vechi ale Player-ului de la VMWare era legată de driverul de rețea, care din motive știute doar de dezvoltatorii de la VMWare nu se mapa corect pe kernel.
Problema, raportată prin 2013 (cel puțin atunci am auzit prima dată de ea), a fost rezolvată odată cu versiunea 6 a playerului.

Și cum lucrurile simple nu puteau rămâne simple, combinația kernel 3. + player 7.x aduce din nou (mai mult sau mai puțin) aceleași probleme…

Pe forumul comunităților sunt prezente multiple soluții care au rezolvat unuia sau altuia problema vmnet-ului… dintre cele testate de mine cea care mi-a rezolvat (deja de două ori problema – întrucât trebuie aplicată după fiecare actualizare de VMWare Player) este următoarea:

$ curl http://pastie.org/pastes/9934018/download -o /tmp/vmnet-3.19.patch
$ cd /usr/lib/vmware/modules/source
$ tar -xf vmnet.tar
$ patch -p0 -i /tmp/vmnet-3.19.patch
$ mv vmnet.tar vmnet.tar.SAVED
$ tar -cf vmnet.tar vmnet-only
$ rm -r vmnet-only
$ vmware-modconfig --console --install-all

Și apoi minune, VMWare Player își poate compila driverele de rețea de câte ori se actualizează el, sau kernelul mașinii.

O copie a fișierului vmnet-3.19.patch am păstrat-o aici.

Eroare Ubuntu: key_from_blob

Din categoria “de notat ca să nu mai pierd vremea pe aceeași temă“.
Se întâmplă servere noi, servere Ubuntu pe care mintea mea în sinea ei se gândește să facă “paswordless ssh”
Toate bune și frumoase, toate setările-s la locul lor, dară orice nouă sesiune ssh continuă să întrebe de parolă… și nu, nu are serverul o viață proprie și personală, chiar loghează încercarea mea de conectare și mai și zice că:


Apr17 10:23:16 r2d2 sshd[8942]: error: key_from_blob: can't read rsa key
Apr17 10:23:16 r2d2 sshd[8942]: error: key_read: key_from_blob BBBBN3WzaA1kc3TPPPCBALZa7U96gJeJm5zHVaP9x1jSKfRdvkmQukV3T1S+096
Vs74gJALn\n failed

Și se uită je ca vițelu’n loguri preț de câteva minute întrebându-se ce mama mă-sii se întâmplă acolo… până ce am văzut minunea… “\n”-ul de la final.

BangingHeadÎn deșteptăciunea mea am copiat și o linie nouă atunci când am pus cheia în fișierul authorized_keys.

Și bineînțeles, ștergerea acelei linii noi a făcut să-mi recunoască cheia la conectare și să funcționească totul așa cum trebuie…. desigur, cu întârzierea de rigoare…

sh2log pentru momentele când vrei să știi.

Sunt momente când mai mulți oameni lucră pe aceeași mașină/server iar pentru a evita discuții inutile, au fost inventate diverse sisteme de monitorizare.

Și, la fel ca în multe alte cazuri, cele mai eficiente se dovedesc a fi cele vechi (oldies but goldies?)

sh2log este un keylogger (de prin 2006), o aplicație care întregistrează toate comenzile care sunt rulate pe o anumită mașină și apoi oferă posibilitatea vizualizării integrale (și foarte interesant – interactive) a unei sesiuni de lucru.

Am apucat să testez această aplicație pe sisteme CentOS(5) și Ubuntu(10.04, 12.04) și nu pot garanta funcționarea pe alte sisteme, așa că nu recomand testarea decât pe mașini de test.

Despre sh2log se poate citi pe pagina dedicată din packet storm.

Singura cerință pentru a putea instala și rula sh2log este să existe biblioteca de development libX11.
Aceasta trebuie instalată înainte de a compila sh2log.

Pe sisteme Ubuntu comanda de instalare este:

$ sudo apt-get install libx11-dev 

În cazul sistemelor CentOS (cu drepturi de root):

# yum install libX11-devel 

După aceasta procesul e foarte simplu.
Întâi trebuie descărcată arhiva, extrase fișierele și compilat sursele.

# wget http://packetstormsecurity.com/files/download/51780/sh2log-1.0.tgz
# tar zxvf sh2log-1.0.tgz
# cd sh2log-1.0
# make linux

Odată compilarea încheiată, trebuie înlocuite executabilele bash și sh (păstrând și o copie a fișierelor inițiale):

#mkdir /bin/shells/
# cp -p /bin/sh /bin/shells/
# cp -p /bin/bash /bin/shells/
# rm -rf /bin/sh /bin/bash
# cp -p sh2log /bin/sh
# cp -p sh2log /bin/bash

La final, după ce toți pașii au fost executați cu succes, se lansează aplicația de monitorizare:

# ./sh2logd

Din acest moment, orice nouă consolă (fizică sau virtuală) va fi înregistrată.
În directorul în care a fost compilată aplicația vor apărea fișiere având nume de tipul sh2log-20140207-082100.bin

Pentru a vizualiza înregistrările se lansează executabilul parser.

# parser sh2log-20140207-082100.bin 

iar apoi se selectează modul în care se dorește a fi făcută vizualizarea.

Deși nu e o practică recomandată, uneori oferă informații utile despre activitățile desfășurate pe un computer.

Cisco AnyConnect și problemele lui în Ubuntu

Dacă ar fi să calculez orele pierdute încercând să dau de cap diferitelor probleme între echipamente și servicii Cisco (fie ele routere nu neapărat ieftine, Webex sau mai nou clienți de VPN), aș crede că la Cisco au rămas doar echipele de dezvoltatori specializați pe .Net.

Nu de alta dar altfel nu-mi explic cum au reununțat de exemplu la suportul pentru Linux și Mac la meetmenow.

Recent am avut o nouă surpriză.

Unul din clienții ne dă acces spre serverele sale, servere aflate într-un VPN. Până aici, nimic nou sub soare. Însă în momentul în care am instalat versiunea pentru Linux a AnyConnect (care printre altele e relativ bine ascunsă și ajungi la linkul spre ea doar după ce crapă componenta Java), când să configurez clentu’ iaca surpriză… acesta nu funcționa, afișând o minunată eroare: “AnyConnect cannot confirm it is connected to your secure gateway. The local network may not be trustworthy. Please try another network.”

Acuma, ce să zic… m-aș fi dus eu în altă cameră, în altă rețea (eventual aia din crâșma vecină) dar conștiința nu și nu… și mă apuc de căutat soluții.

Cu puțin noroc (a fost o zi cu karmă bună) am găsit pe oit.ncsu.edu soluția problemei mele, se pare că pentru a aplicația se uită aiurea după certificatele, în special la CA prezente în sistem.

După ce am făcut structura de directoare pe placul său – /opt/.cisco/certificates/ca/ am copiat în directorul ca toate fișierele din  /etc/ssl/certs.

$sudo cp /etc/ssl/certs/* /opt/.cisco/certificates/ca 

Nu am testat, dar e posibil ca un link simbolic să rezolve de asemenea problema.

Ce este de asemenea de ținut minte, Cisco AnyConnect nu merge dacă este lansat ca root (cu sudo).

BIOS-uri idioade vs LVM = timp pierdut, nervi și mulți morcovi….

Se pare că uneori, după ce reușesc să rezolv unele probleme, mintea mea izolează (șterge sau ce-o face ea) evenimentul… și din păcate (uneori) soluția găsită.

Pe tiparul acesta, zilele trecute când un coleg a venit cu un harddisk bușit am stat și am dat cu presupusul mai bine de o oră până când am găsit rezolvarea.

Problema era că acel hard fusese introdus într-o mașină (mai veche) al cărei BIOS a hotărât că SATA trebuie tratat ca RAID. Drept pentru care a bușit partiția. Cum discul era inițial era LVM, de aici start distracție.

Acum câteva luni am avut parte de o distracție similară, când unul din serverele unui client a cedat iar când a sosit serverul nou, discul vechi nu a mai putut fi folosit dar după cum ziceam, memoria mea se dovedește a fi scurtă, scurtă…

Dar, revenind la cazul acesta, după ce am reușit să refac sistemul de fișiere cu Testdisk, am obținut doar mesajul de oroare atunci când încercam să montez partiția cu pricina:

mount: unknown filesystem type 'LVM2_member'

Fdisk-ul afișa corect partițiile și sistemul însă de pomană.

După înjurături și căutări care în marea majoritate îmi întorceau răspunsuri de tipul “formatează și pune din backup” am (re)găsit soluția salvatoare… și mi s-au activat senzorii

Am instalat lvm2, apoi cu un lvmdiskscan am obținut lista partițiilor:

# lvmdiskscan
/dev/ram0 [ 62.50 MB]
/dev/ram1 [ 62.50 MB]
/dev/hda1 [ 101.94 MB]
/dev/sda1 [ 39.19 MB]
/dev/ram2 [ 62.50 MB]
/dev/hda2 [ 485.58 GB] LVM physical volume
/dev/sda2 [ 2.01 GB]
/dev/ram3 [ 62.50 MB]
/dev/sda3 [ 60.00 GB]
/dev/ram4 [ 62.50 MB]
/dev/sda4 [ 86.96 GB]
/dev/ram5 [ 62.50 MB]
/dev/ram6 [ 62.50 MB]
/dev/ram7 [ 62.50 MB]
/dev/ram8 [ 62.50 MB]
/dev/ram9 [ 62.50 MB]
/dev/ram10 [ 62.50 MB]
/dev/ram11 [ 62.50 MB]
/dev/ram12 [ 62.50 MB]
/dev/ram13 [ 62.50 MB]
/dev/ram14 [ 62.50 MB]
/dev/ram15 [ 62.50 MB]
0 disks
21 partitions
0 LVM physical volume whole disks
1 LVM physical volume

După care, cu lvmdisplay, am obținut numele volumului

# lvmdiskscan
lvdisplay
--- Logical volume ---
LV Name /dev/VolGroup00/LogVol00
VG Name VolGroup00
LV UUID xxxxxxxxx

și toate celelalte componente ale sale.

Cu toate astea și încercarea de a monta volumul folosind numele a fost un eșec.

# mount /dev/VolGroup00/LogVol00 /mnt/tempdisk/
mount: special device /dev/VolGroup00/LogVol00 does not exist

La scanare am văzut că statusul e inactiv:

# lvscan
inactive '/dev/VolGroup00/LogVol00' [485.58 GB] inherit
inactive '/dev/VolGroup00/LogVol01' [14.42 GB] inherit

Apoi, mulțumită unui “pățit”  am găsit soluția:

# modprobe dm-mod
# vgchange -ay
# lvscan
ACTIVE '/dev/VolGroup00/LogVol00' [485.58 GB] inherit
ACTIVE '/dev/VolGroup00/LogVol01' [14.42 GB] inherit
# mount /dev/VolGroup00/LogVol00 /mnt/tempdisk

Și am făcut un om fericit că-și poate accesa datele de pe discul cu pricina.

Conectarea la o mașină Ubuntu prin RDP

Se făcu’ că prin conjucția unor planete (nu știu care) o companie ia hotărârea să renunțe la folosirea Windows pe computerele din anumite departamente. O decizie salutară… care însă a născut o problemă: cum se mai pot face conexiuni la distanță pe acele mașini, de pe stațiile de lucru care încă rulează Windows, fără a instala pe acestea din urmă nici o aplicație suplimentară.
Pam, pam… temă de casă.
După momentul Kodak… am propus soluția RDP prin VNC :D… toată lumea a fost fericită… amu’ rămâne doar să fie pusă în practică… iar cum în spatele meu nu era nimeni caruia să-i “pasez pisica”… am suflecat mânecile de la maiou și… am purces la căutări.
Din fericire, soluția există și culmea… mai și funcționează… așa că, pentru nemurirea informațiunii (vorba volant):
În primul rând, soluția funcționează pe Ubuntu 12.04 (adică pe versiunea asta am testat, e posibil să funcționeze și pe altele însă… eu nu știe).

Prima dată trebuie permis accesul remote:
– Click pe dash, scris “desktop” și clic pe “Desktop Sharing” iar apoi se bifează prima opțiune “Allow other users to view your desktop”. Clic pe “Close”.
desktopsharing

În momentul acesta, în teorie “vino”  este instalat și are o configurație de bază.

Amu’ e momentul instalării xrdp

$ sudo apt-get update && sudo apt-get --no-install-recommends install xrdp 

Partea cu –no-install-recommends nu am știut-o la început și m-am trezit cu o căruță de lucruri care au făcut să nu-mi funcționească conexiunea…
Pe parcursul instalării trebuie citit cu atenție ce “varsă” terminalul și nu în ultimul rând, cheile sunt generate corect și salvate corespunzător.

Acum trebuie să configurăm vino:

$ sudo vi /usr/share/applications/vino-preferences.desktop 

Aici trebuie comentată linia
OnlyShowIn=GNOME;

Salvat/închis.

Iar apoi, trebuie să-i spunem și xrdp-ului că trebuie să lucre prin vncc

$ sudo vi /etc/xrdp/xrdp.ini 

În care trebuie să rămână doar:

[globals]
bitmap_cache=yes
bitmap_compression=yes
port=3389
crypt_level=low
channel_code=1

[xrdp1]
name=RDP2VINO
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=5900

Salvat, închis și restartat serviciul

$ sudo service xrdp restart 

În mod normal, atât ar trebui să fie suficient pentru a putea folosi clientul de Remote Desktop din Windows pentru a efectua o conexiune la o stație Ubuntu.

În cazul în care nu e ziua aceea norocoasă și conexiunea nu se întâmplă… ar mai fi de gâdilat:

De exemplu, dacă după conectare apare doar un desktop gol (cum am avut eu nenorocul pe 2 stații de lucru) trebuie forțat xrdp să folosească ubuntu-2D (sau gnome-fallback) ca environment pentru desktop.
Pentru a face asta, trebuie creeat în directorul utilizatorului, un fișier pe numele lui .xsession care să conțină:

gnome-session –session=ubuntu-2d 

În cazul meu asta fost suficient pentru a face lucrurile să funcționeze conform cerinței.

Orice hard poate fi umplut…

Și bineînțeles, de cele mai multe ori, cu cât e discul mai mare, cu atât mai puțină atenție va primi… Și așa se face că azi dimineață, după un upgrade m-am trezit că partiția mea de boot mai are doar 200Kb liberi… și că noul kernel care vrea să se instaleze acolo…. nu prea mai are pre unde.

Și m-am apucat eu să caut prin linkurile salvate hăt prin toate browserele folosite în cursul timpului și am dat de un link (de prin 2011, probabil ultima dată când m-am confruntat cu o problemă asemănătoare) care oferă probabil cea mai rapidă soluție de curățenie:

 $ dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge 

remove_kernel

Și se făcu așadar lumină-n sat și 4Gb am câștigat 🙂  și pre acilea am notat… ca data viitoare să nu mai caut ca orbu’ Brăila.

© 2009-2019 Alex. Burlacu
%d bloggers like this: