Archive for the ‘Servers’ Category

Extindere spatiu LVM pe Ubuntu pentru VM-uri care ruleaza pe Hyper-V

lvmPentru extinderea spatiului unei masini virtuale care ruleaza pe Hyper-V (sau pe orice alta platforma de virtualizare) procedura este ceva mai complexa decat pe Windows unde totul se face foarte interactiv din Disk Management. Astfel, dupa extinderea din Hyper-V, cand masina virtuala reporneste, spatiul suplimentar apare ca si freespace .

Prima comanda care o rulam este:

parted

care ne arata partitiile existente si ce este folosita (Using /dev/sda), iar aici daca rulam „print free” o sa putem vedea free space-ul cu spatiul suplimentar extind in Hyper-V. Acum putem partitiona spatiul free. Accesam

cfdisk

unde creem din „Free Space” o partitie noua (Primary sau Logical) urmand ca apoi face Write la partition table in cfdisk.

E important un reboot la server acum.

Dupa reboot rerificam daca noua partitie exista:

fdisk -l /dev/sda

si o sa o gasim partitia FreeSpace facuta mai devreme in cfdisk, denumita ca si Linux si /dev/sdaX)

Acum urmeaza sa punem partitia /dev/sdaX facuta din freeSpace in LVM:

pvcreate /dev/sdaX

O verificam

pvdisplay

unde o sa vedem ca ultima partitie nou creata este /dev/sdaX

Acum urmeaza sa extindem volumul:

vgextend nume_vg /dev/sdaX

unde nume_vg il gasim la pvdisplay.

Verificam efectuarea cu

lvdisplay

Acum urmeaza extinderea la logical volume

lvextend -l+100%FREE /dev/nume_vg/root

Apoi face resize la filesystem:

resize2fs /dev/mapper/nume_-vg-root

Si in final putem observa spatiul suplimentar ruland:

df -h

Incarcarea firewallului iptables la root pe Debian/Ubuntu

APF-Linux-Firewall1Cu totii stim ca iptables isi pierde toate setarile in momentul in care sistemul a fost restartat. Astfel, dupa ce ne-am asigurat ca totul functioneaza corect cu regulile de firewall actuale, putem face o salvare a lor ca sa fie tinute minte si incarcate la fiecare pornire de sistem.

Prima data putem verifica regulile folosind comanda

iptables -L sau iptables –list

Daca regulile gasite aici sunt cele corecte, urmeaza sa procedam la salvarea lor intr-un fisier, eu am ales sa il numes firewall.conf

iptables-save > /etc/firewall.conf

iar acum creem scriptul care va incarca regulile la ficare bootare a sistemului.

echo ‘#!/bin/sh’ > /etc/network/if-up.d/iptables
echo ‘iptables-restore < /etc/firewall.conf’ >> /etc/network/if-up.d/iptables

chmod +x /etc/network/if-up.d/iptables

 

Montare partitii LVM pe Ubuntu

Montarea palvmrtitiilor LVM pe Ubuntu se face putin diferit fata de stick-uri, cd/dvd-uri, hdd extern etc.

Primul pas este sa instalam lvm2

apt-get install lvm2

Apoi scanam partitiile logicale existente pe sistem:

vgscan

Daca partitia are un nume mai dificil o redenumim folosind:

vgchange -ay NumeVolum00

Localizam volumul care este declarat ca root pentru a folosi numele la montarea acestuia:

lvs

Creem un folder pentru mount point:

mkdir /mnt/lvm

Montam efectiv partitia LVM:

mount /dev/NumeVolum00 /

 

SAMP cu Solaris

solarisInstalarea pachetului SAMP (Solaris Apache MySQL PHP) se face destul de usor, avand in vedere ca ne pune la dispozitie o comanda care face acest lucru.

pkg install amp

Odata instalate, aceste pachete trebuie puse si pe enable, altfel ele nu vor porni, asa cum la alte sisteme de operare se intampla.

svcadm enable apache22

svcadm enable mysql

Aceste doua comenzi fac enable si pornesc cele doua servicii.

In cazul in care dorim sa facem restart la aceste servicii, rulam:

svcadm restart apache22

svcadm restart mysql

In mod implicit MySQL se instaleaza fara sa se aloce nici o parola pe userul root, iar pentru modificarea parolei trebuie sa ne conectam la serverul de mysql si apoi sa ii alocam o parola:

mysql sau mysql -u root -p

SET PASSWORD FOR root@localhost=PASSWORD(‘parola_alocata’);

Solaris 11 – instalare pachete

solarisPe sistemul de operare Solaris, pachetele se instaleaza folosind comanda ‘pkg’.

pkg install nume_pache

Pentru cautarea pachetelor se ruleaza pkg search nume_pachet

ex: pkg search apache2

care returneaza numele pachetului apache-22 si se poate rula pkg install apache-22

Backup si restore la o baza de date MySQL in si din fisier gzip (*.sql.gz)

Putem efectua backup (dump) la o baza de date MySQL direct intr-un fisier arhivat cu gzip, adica sql.gz

mysqldump -u username -pPassword nume_baza_de_date | gzip >  nume_fisier_backup.sql.gz

De asemenea putem efectua restore la o baza de date MySQL in cazul in care acesta este deja arhivata intr-un fisier gzip, adica .sql.gz

gunzip < nume_fisier_backup.sql.gz | mysql -u username -pPassword nume_baza_de_date

Pornirea accesului remote la MySQL pentru un utilizator

imagesIn unele cazuri este necesar sa avem pornit accesul la MySQL pentru unul sau mai multi useri, pentru a evita bataile de cap si timpul pierdut la rularea comenzilor de mysqldump si restore a bazelor de date, iar operatiunile sa le putem efectua de la distanta direct pe serverul de baze de date.

Din punctul meu de vedere, acesta nu este un acces care sa fie deschis permanent, asa ca il folosesc doar pe perioada in care este nevoie de el.

Asadar, pentru a aloca accesul din exterior la un server MySQL, folosind un username specific, efectuam urmatoarele.

mysql -u root -p

GRANT ALL PRIVILEGES ON baza_de_date.* TO ‘username’@’%’ IDENTIFIED BY ‘parola’;

Apoi editam /etc/mysql/mycnf unde adaugam linia:

bind-address = 0.0.0.0

pentru a permite accesul din afara.

Cand vrem ca accesul din exterior sa nu mai fie disponbil, prima data comentam linia din my.cnf adaugata anterior si apoi facem REVOKE la privilegii:

mysql -u root -p

REVOKE PRIVILEGES ON baza_de_date.* TO ‘username’@’%’;

Intelegerea UMASK intr-un sistem UNIX based

UMASKCel mai pe scurt putem spune ca UMASK se ocupa de alocarea permisiunilor pentu fisiere si foldere intr-un sistem de operare UNIX based, bazandu-se pe o setare implicita data de administratorul sistemului.

Inainte de toate trebuie stabilit ca in cadrul fisierelor si folderelor permisiunile se aloca dupa regula:

4 – read

2 – write

1 – execute

In mod implicit UMASK-ul este setat la modul permisiv, adica 022 pentru root si 002 pentru userii obisnuiti, iar el poate fi modifica editant /etc/profile sau ~./bashrc.

UMASK 022, folosit pentru root, inseamna ca folderele create vor avea permisiuni de 755, iar fisierele de 644, mai precis ownerul poate scrie si modifica datele, dar restul userilor le pot doar vizualiza.

UMASK 002, folosit pentru userii obisnuiti din sistem, uinseamna ca folderele vor avea permisiuni de 775, iar fisierele de 664, mai precis ownerul poate scrie si modifica datele, grupul din care face parte userul, poate si el, iar ceilalti pot doar sa le vizualizeze.

 

 

 

Calcularea UMASK se face dupa urmatoarele reguli:

0 – Read Write Execute

1 – Read Write

2 – Read Execute

3 – Read

4 – Write Execute

5 – Write

6 – Execute

7 – No Permissions

Asadar:

022 – Owner: RWX, Group: RX, Others: RX

002 – Owner: RWX, Group: RWX, Others: RX

077 – Owner: RWD, Group: No permissions, Others: No permissions

026 – Owner: RWX, Group: RX, Others: X

027 – Owner: RWX, Group: RX, Others: No permissions

Active Directory HTTP authentication folosind authnz_ldap cu Apache2

In multe cazuri este necesara autentificarea cu Active Directory la nivel de Apache2, in special cand discutam de un numar mare de utilizatori care acceseaza un portal web din locatii diferite si mai ales atunci cand vrem ca accesul sa fie cat mai restrans la persoanele dintr-o companie pe care de altfel sa nu ii incarcam cu un user si o parola pentru fiecare resursa existenta.

Astfel, configurarea consta in prima faza in adaugarea unei linii in fisierul: /etc/ldap/ldap.conf care sa arate asa:

REFERRALS off

si prin care specificam sa nu fie restrictionate referintele la un server printr-un site in special cand interogarile vin prin web pentru ca autentificarea cu Active Direcotry sa fie posibila si prin web.

Mai departe am trecut la partea de configurare a autentificarii prin Active Directory si in interiorul <Directory /var/www/>    </Directory>  am adaugat urmatoarele linii:

AuthBasicProvider ldap
AuthType Basic
AuthName „Restricted Zone”
AuthLDAPURL „ldap://nume_server_dc.tld:389/DC=nume_server_dc,DC=tld?sAMAccountName?sub?(objectClass=user)” NONE
AuthLDAPBindDN „user_creat_in_ad@DOMENIU”
AuthLDAPBindPassword „parola_userului_creat_in_ad”
require ldap-attribute objectClass=user

Detalii despre fiecare linie se gasesc aici: http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html

Daca toate datele introduse au fost corecte, in mod normal autentificarea trebuie sa se efectueze fara probleme din web. Inainte de testare trebuie restartat Apache2.

/etc/init.d/apache2 restart

Mai departe am dorit ca doar cei din exteriorul retelei sa aiba restrictia de a introduce user si parola, iar cei din interiorul retelei, sau cei care au adresele IP specificate de mine sa nu aiba aceasta problema. Atunci am mai adaugat inainte de AuthBasicProvider ldap linia:

order deny allow

iar dupa require ldap-attribute objectClass=user am adaugat liniile prin care am specificat adresele IP care sa aiba acces fara autentificare HTTP:

satisfy any

deny from all

allow from 172.16.16.1/24

allow from 1.2.3.4

unde 172.16.16.1/24 reprezinta o clasa de adrese IP care se pot aloca unei retele interne, iar 1.2.3.4 reprezinta un IP extern sau intern.

sFTP server cu Debian si chRoot jail pentru useri

sftpServerul sFTP functioneaza prin SSH, mai precis pe portul 22. Intamplarea a facut sa am nevoie de un astfel de server, unde bine-nteles ca nu era suficient un simplu FTP intrucat era nevoie ca transferul sa se faca in mod securizat.

By default cand instalezi un sistem de operare, te poti autentifica cu userii locali si prin sFTP insa apare problema ca un user poate vizualiza toate folderele serverului, lucru care nu ne-ar conveni sub nici o forma. Astfel, vom apela la metoda chroot jail pentru userii creati. Autentificarea cu toate ca se face pe portul 22 (SSH) userilor nu le vom da drept de conectare SSH, doar sFTP.

Primul pas este sa creem un grup unde toti userii v vor fi adaugat. Il voi numi sftpusers:

groupadd sftpusers

Apoi vom crea un user ‘john’ care va avea home folder /incoming si shell-ul /sbin/nologin pentru a-i interzice logarea prin SSH.

useradd -g sftpusers -d /incoming -s /sbin/nologin john

Acum ii alocam o parola userului john:

passwd john

Userul il putem verifica in /etc/passwd

cat /etc/passwd

Acum trebuie sa facem cateva modificari in fisierul /etc/ssh/sshd_config. Asadar, inlocuim linia:
#Subsystem sftp /usr/libexec/openssh/sftp-server

cu

Subsystem sftp internal-sftp

Dupa ce am facut aceasta modificare, mai trebuie sa adaugam tot in acest fisier cateva linii care spun ca vom face chroot doar pentru userii folderul sftp.
Match Group sftpusers
ChrootDirectory /sftp/%u
ForceCommand internal-sftp
Match Group sftpusers – indica faptul ca urmatoarele linii se aplica doar utilizatorilor din grupul sftpusers.

ChrootDirectory /sftp/%u – indica locul in care userii vor avea chroot dupa autentificare

ForceCommand internal-sftp – este o comanda care forteaza executia internal-sftpsi ignora alte comenzi mentionate in ~/.ssh/rc

Urmeaza sa creem directorul sftp.

mkdir /sftp

,iar in interiorul acestui folder vom crea un alt folder care va purta numele fiecarui utilizator creat. In cazul nostru:

mkdir /sftp/john

Acum /sftp/john este echivalentul „/” pentru userul john. Ca sa izolam utilizatorii, sa nu poata vedea ce alti urtilizatori mai exista sau ce foldere mai contine /sftp, vom crea in interiorul folderului /sftp/john un director numit: incoming, prin care vom pune in valoare chroot-ul.

mkdir /sftp/john/incoming

Mai trebuie sa punem permisiuni relevante user:sftpusers pe acest folder „incoming”:

chown john:sftpusers /sftp/john/incoming

Ultimul pas este sa restartam serviciul SSH executand comanda:

/etc/init.d/ssh restart

urmand apoi sa testam in FileZilla conexiunea pe sFTP.

srv StandDuPp
Articole recente