Categories
Linux

Structura sistemului de fișiere Linux.

Pentru a evita întrebările ulterioare de tipul: “Da’ de ce în /media și nu în /mnt”

LinuxDirectoryStructure

@via tecmint.com

Categories
Linux

Ștergerea selectivă a liniilor din history

Nu de puține ori am avut de curățat linii de prin history.

Și cum “-d” e un (citez un amic) “parametru puturos”, am căutat o soluție de a șterge selectiv înregistrările.

Scriptul care rezolvă problema l-am găsit astă vară iar acum îl pun și aici, nu de alta dar e mai ușor decât să-mi fac ordine în bookmarci.

Pentru a rula corespunzător, scriptul trebuie să fie lansat cu “source” sau cu “.”

După ce liniile dorite au fost șterse, ce a rămas se poate scrie îm memorie cu “history -w”.

Scriptul poate fi descărcat de aici (clic de dreapta și “save link as”).

history_delete

Folosit fără parametri suplimentri, scriptul va șterge ultimele 35 de înregistrări.

Pentru a șterge un anumit număr de înregistrări sau un interval este necesară specificația numărului de linii/intervalului, de exemplu:

# source delete_hitory 50 

va șterge ultimele 50 de linii din history

# source delete_hitory 50-70 

va șterge toate înregistrările de la linia 50 la linia 70

# source delete_hitory 50- 

va șterge toate înregistrările începând cu linia 50

Scriptul a fost pus de utilizatorul Kenhelm pe linuxquestions prin 2010.

 

 

Categories
Ubuntu

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.

Categories
Ubuntu

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).

Categories
De-ale mele Linux

Oameni înfometați….

De când cu atâtea variațiuni pe temă dată (distribuții GNU/Linux, sisteme de operare mobile etc) încep să cred că, așa la modul general, foamea de informație vine din stomac 🙂

Nu de alta dar nu e zi să nu aud de YUM, Yaourt, Ice Cream Sandwitch, Kit Kat și alte lucruri care-mi excită găurile din stomac într-un mod nu neapărat plăcut…

Nu știu dacă prin KDE mai găsesc chocolat…. însă dacă mai scriu mult despre asta îmi va pluti tastatura…

Categories
Gadgeturi Linux

SkyJack, caută, convinge și aduce acasă dronele (altora)

Nu (mai) este un scenariu de film SF…. nu că n-aș fi văzut aduse la viață (în viața asta, culmea) mai toate ideile interesante din filmele copilăriei… dar asta-i cea mai recentă.

Mai săptămâna trecută citeam știrea conform căreia Amazon testează serviciul de livrări utilizând drone, drone care-ți lasă pachetu’n fața ușii și-și văd cuminți (și ieftin, fără a cere drepturi sindicale, dar asta e altă discuție) de treabă. Bine, asta funcționează (va funcționa) în țări “pă’ orizontală” că la mine-n bloc în afară de hoți, polițai și ăia de aduc biblii (cam toți în aceeași echipă nu-i așa?) nu nimerește mai nimeni etajul. Până și găgâl îmi arată pe hărțile astea actualizate blocul mai la două străzi de unde e el de fapt 🙂

Foto: BBC

Dar, revenind la livrările cu drone… numa’ bine ce-a povestit Amazon de ideea de a expedia pachete cu drone și au apărut primele încercări de deturnare a dronelor. Și despre un astfel de proiect voi povesti eu acuma.

Pre numele lui SkyJack, proiectul dezvoltat de @SamyKamkar propune o dronă care știe să caute singurică semnalul altor drone aflate în zbor, apoi prin fireless prea controlul asupra dronelor găsite și le transformă (așa cum spune inventatorul) într-o armată de drone zobmie aflate sub controlul tău.

Nu toate dronele pot fi atacate, momentan aplicația poate deturna doar dronele Parrot AR.Drone folosindu-se de adresele MAC ale companiei Parrot.
Aplicația este disponibilă în githul și este scrisă în perl, așa că poate rula pe orice mașină GNU/Linux, folosește aircrack-ng pentru a pune în modul de monitorizare placa sa wi-fi,apoi folosește aireplay-ng pentru a scoate drona de sub controlul proprietarului de drept și la final, folosind node-ar-drone (Javascript și node.js) controlează drona spre casă.

Ca dispozitive fizice, au fost testate și funcționează: o dronă Parrot AR.Drone 2, un Raspberry Pi, un adaptor fireless Alfa AWUS036H și unul USB Edimax EW-7811Un și o baterie USB.

youtube::EHKV01YQX_w::

Sursele pot fi accesate de la https://github.com/samyk/skyjack iar pagina de urmărit pentru viitoarele faze ale proiectului este http://samy.pl/skyjack

Categories
Ubuntu

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.

Categories
Ubuntu

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.

Categories
Ubuntu

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.

Categories
Linux

Mici probleme cu Munin 1.2.5 după un upgrade hardware

Se întâmplă că unul dintre clienți și-a upgradat serverele…. Toate bune și frumoase, performanțele sunt vizibile… însă apar și bubele.

Munin-ul de acolo a fost instalat în mezoliticul timpuriu și a rămas neactualizat atunci când acest lucru s-ar fi putut face fără pierderea graficelor și a datelor istorice.

Astfel că acum după ce au apărut mai multe procesoare decât se aștepta să vadă Munin acolo iar conexiunea la rețea este de asemenea mult mai rapidă… s-a întâmplat că datele din grafice nu mai prezintă realitatea.

Dacă pentru problema traficului pe plăcile de rețea am putut înlocui plugin-ul if_ cu ip_, pentru procesor am avut de săpat.

Până la urmă, afișarea poate fi “reparată” prin modificarea unei linii în plugin-ul cpu.
La linia 72 (presupun că numărul liniei poate varia) se află:

 NCPU=`expr \`grep '^cpu. ' /proc/stat | wc -l\` - 1` 

Pentru a afișa din nou corect graficul cpu când serverul are mai mult de 8 procesoare, linia trebuie modificată încât să arate astfel:

 NCPU=`expr \`grep '^cpu.\{1,2\} ' /proc/stat | wc -l\` - 1` 

În următoarele minute de după restartarea munin-node graficul cpu ar trebui să arate valori corecte care să fie reprezentative pentru toate procesoarele din sistem.

Pentru a activa pluginul ip_ in locul if_ sunt necesari următorii pași:

1 – În fișierul de configurare munin-node (de obicei în calea etc/munin/plugin-conf.d/munin-node) se adaugă:

[ip_*]
user root 

2 – Se creează o regulă în iptables pentru a colecta datele pe un ip specific:

 iptables -A INPUT -d <ip>;iptables -A OUTPUT -s <ip> 

3 – Se instalează plugin-ul pentru ip-ul specificat la pasul anterior:

  ln -s /usr/share/munin/plugins/ip_ /etc/munin/plugins/ip_<ip> 

4 – Se restartează munin-node.

Pașii 2 și 3 se repetă pentru fiecare ip pe care vrem să-l vedem în graficele Munin.