Adresa IP reală în logurile Apache, care funcţionează în spatele unui Proxy

Dacă WEB serverul Apache funcţionează în spatele unui Proxy (de exemplu AWS Elastic Load Balancer, Nginx sau Varnish), atunci, implicit, el va înregistra în loguri adresa acestui Proxy server în loc de adresa reală.
Ceea ce face imposibilă blocarea diferitor atacuri şi monitorizarea traficului, de exemplu.

Una din cele mai simple soluţii este utilizarea modului mod_remoteip pentru Apache 2.4 (apache 2.2 utilizează modului mod_rpaf în acelaşi scop).

Setarea este următoarea:

  1. Se activează modului remoteip:
    a2enmod remoteip
  2. Se modifică fişierul /etc/apache2/apache2.conf (pentru Debian şi Ubuntu), înlocuind %h cu %a în următoarele rînduri:
    LogFormat „%v:%p %h %l %u %t \”%r\” %>s %O \”%{Referer}i\” \”%{User-Agent}i\”” vhost_combined
    LogFormat „%h %l %u %t \”%r\” %>s %O \”%{Referer}i\” \”%{User-Agent}i\”” combined
    LogFormat „%h %l %u %t \”%r\” %>s %O” common
  3. În acelaşi fişier de configurare se adaugă:
    RemoteIPHeader X-Forwarded-For
    RemoteIPTrustedProxy 1.2.3.4 (indicaţi adresa serverului Proxy)
    RemoteIPTrustedProxy 5.6.7.8 (indicaţi adresa serverului Proxy)
  4. Se reporneşte serverul Apache:
    service apache2 restart

Pentru CentOS: http://gurutek.biz/mod_rpaf-and-mod_remoteip/

Sincronizarea datelor între două servere cu LsyncD

Pentru sincronizarea datelor între servere, de obicei se folosește rsync pornit de un cronjob. Dar acesta presupune verificarea tuturor fișierelor dintr-o mapă ceea ce consumă resurse și timp în cazul unui volum mare de date.

LsyncD monitorizează fișierele modificate și le sincronizează doar pe ele, astfel impactul asupra performanței este practic nul. Pentru asta LsyncD utilizează inotify / fsevents.

Sincronizarea datelor este necesară cel mai des în cazul balansării sarcinii între două WEB Servere și mai multe, cînd conținutul dintre ele trebuie mențiunut identic.

Setările din acest tutorial au fost verificate pe sisteme Debian 7.9 și lsyncd 2.0.7.

Se instalează pachetele necesare:

apt-get install lsyncd pkg-config lua5.2 liblua5.2 rsync

Se adaugă mapă pentru setările lsyncd:

mkdir /etc/lsyncd/

Se adaugă fișierul de configurare:

vim /etc/lsyncd/lsyncd.conf.lua

Se inserează următorul conținut în el:

settings = {
logfile = "/var/log/lsyncd.log",
statusFile = "/var/log/lsyncd.status",
statusInterval = 10
}
sync {
default.rsync,
source="/var/www/",
target="server2.md:/var/www/",
delete = false,
rsync = {
compress = true,
acls = true,
verbose = true,
owner = true,
group = true,
perms = true,
delete = false,
rsh = "/usr/bin/ssh  -o StrictHostKeyChecking=no"
}
}

În loc de server2.md se indică numele sau adresa IP a celui de-al doilea server. Pentru source și target se indică dosarele corespunzătoare. Pentru al doilea server se procedează la fel, indicîndu-se corect numele/adresa primului server.

Parametrul delete = false este foarte important în cazul dat, pentru că în caz contrar foarte ușor s-ar putea pierde date în caz de careva probleme de sincronizare.

Pe primul server se generează o cheie de securitate pentru utilizatorul root:

ssh-keygen -t rsa

Se afișează conținutul cheiei private:

cat /root/.ssh/id_rsa.pub

Cheia are următoarea formă:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDAvmyHLLtwnZY9xDFOLV1oKteecmfukqgT+nK0Yr5DMySM7gvqNKiJbIjdxnYrpuQP1mNYWWCtvgf146LUiC9bVjeZIgjZZl93yi5PGKLGSknTNB0pQVNWx3aT6+UqbtEJVBUHWCu3KxWD5VIXD0gIpnqyPbIVft5hZXzmGZ2+F+TF6S++W5ygiYD47GkC9Ljs2iwvl6xKxlkRuZ4lrgsQng92AErBAjsH+dVGQx0I3niZEcCMagp4KOadxrEoqH/uEbr8i+MyaE1wG8opqsZ5KueCBvEdPS+K3S9DQ4D1MxHml2YVfgr/aGozb0rUpTJU9OQE1Qsy63HGt+VLTAOD root@server1.md

Se inserează această cheie în fișierul /root/.ssh/authorized_keys de pe cel de-al doilea server.

În același mod se generează o cheie pe serverul al doilea și se autorizează conexiunea pe primul server.

Aceeași procedură se folosește pentru a permite conexiunea dintre servere fără parole.

Se pornește serviciul LsyncD:

service lsyncd start

Se verifică logurile pentu a determina dacă sincronizarea funcționează:

cat /var/log/lsyncd.log

Pentru monitorizare continuă:

tail -f /var/log/lsyncd.log

Salvarea setărilor curente pentru iptables ca script sh

Pentru aceasta vom folosi un script perl.  Creați un fișier cu numele:

mkscript.pl

Adăugați în el următorul conținut:

#!/usr/bin/perl 
use strict;

if (@ARGV && $ARGV[0] =~ /^-/) {
	print 'converts an iptables-save file to a shell script',
	"\nUse: $0 [filename]\n";
	exit 0;
}

open I, shift || '-' or die $!;

my($table,$ipt);

print "#!/bin/sh
#iptables script, generated from iptables-save file
IPT='/sbin/iptables'
";

while (<I>) {
	if (/^\s*(#|$)/) {
		print;
		next;
	}
	if (/^\*(.*)/) {
		$table = $1;
		$ipt = $table eq 'filter' ? '$IPT' : '$IPT -t '.$table;
		print "$ipt -F\n";
		print "$ipt -X\n";
		next;
	} elsif (/^COMMIT/) {
		$table = 0;
		next;
	}
	die unless $table;
	if (/^:(\S+) +([^- ]\S*)/) {
		print "$ipt -P $1 $2\n";
		next;
	} elsif (/^:(\S+)/) {
		print "$ipt -N $1\n";
		next;
	}
	s/^\[[0-9:]+\]\s*//;
	die unless /^-A/;
	print "$ipt $_";
}

Folosiți următoarea comandă pentru a genera scriptul:

iptables-save | mkscript.pl > /etc/firewall.sh

Convert iptables-save output to shell script.

Configurarea serverului ProFTPD pentru autentificare cu utilizatori de sistem şi conexiune SFTP

Implicit, serverul SSH pe sisteme GNU/Linux permite transferul de date prin protocolul SFTP. Pentru un sistem care nu implică conexiunea persoanelor cu drepturi restricţionate, e suficient.

Dar dacă este nevoie de a configura accesul unor persoane terţe, atunci apare necesitatea de izola aceşti utilizatori. Cea mai simplă şi funcţională soluţie în cazul dat este configurarea unui server FTP ce va lucra şi pe protocolul SFTP, pe un port aparte.

În acest exemplu vom utiliza ProFTPD şi un sistem de operare Ubuntu/Debian.

Instalăm serverul ProFTPD:

apt-get update && apt-get install proftpd

În fişierul /etc/proftpd/conf.d/sftp.conf adăugăm următorul conţinut:

<IfModule mod_sftp.c>
 SFTPEngine on
 Port 2222
 SFTPLog /var/log/proftpd/sftp.log
 SFTPHostKey /etc/ssh/ssh_host_rsa_key
 SFTPHostKey /etc/ssh/ssh_host_dsa_key
 SFTPAuthMethods password
 SFTPCompression delayed
 </IfModule>

În fişierul /etc/proftpd/proftpd.conf decomentaţi şi modificaţi (sau adăugaţi dacă lipsesc) următoarele rînduri:

DefaultRoot ~
 PassivePorts 50000 50010
 AuthOrder mod_auth_pam.c* mod_auth_unix.c

Dacă doriţi să dezactivaţi posibilitatea de conectare SFTP oferită de SSH (pe portul 22), atunci comentaţi (sau ştergeţi) în fişierul /etc/ssh/sshd_config următorul rînd:
Subsystem sftp /usr/lib/openssh/sftp-server

Reporniţi serverul ProFTPD:

service proftpd restart

Reporniţi serverul SSH (dacă aţi făcut modificări în el):

service ssh restart

Pentru autentificare se for folosi datele utilizatorilor din sistem. Pentru a adăuga un utilizator nou folosiţi instrucţiunea:

adduser numele_utilizatorul

Pentru conectare puteţi folosi FileZilla sau oarecare alt client. Setările sînt următoarele:
Host: hostname sau IP
Port: 2222
Protocol: SFTP
User: numele_utilizatorul
Password: parola_utilizatorului

Apache/PHP, Sendmail și SELinux împreună

SELinux este un modul de securitate a nucleului linux. Implicit, SELinux nu permite ca WEB-Serverul Apache să poată expedia mesaje prin intermediul componentei Sendmail, afișînd în mail.log următoarea eroare:
NOQUEUE: SYSERR(apache): can not chdir(/var/spool/clientmqueue/): Permission denied

Această eroare poate induce în eroare, pentru că e un banal mesaj ce indică permisiuni greșite asupra dosarului. Variabila SELinux care gestionează permisiunea de expediere este httpd_can_sendmail

Pentru a verifica ce valoare are, se folosește instrucțiunea:

getsebool -a | grep httpd_can_sendmail

Rezultat:

httpd_can_sendmail --> off sau httpd_can_sendmail --> on

Dacă rezultatul este off, atunci trebuie setat în on pentru a permite expedierea mesajelor. Se folosește instrucțiunea:

setsebool -P httpd_can_sendmail 1

Rapoarte zilnice despre activitatea postfix

Dacă aveți un server pe linux, care are configurat un server poștal postfix, puteți vedea zilnic statistica mesajelor. Unul din instrumentele care vă permit acest lucru este scriptul PFLogSumm: https://calomel.org/pflogsumm.html.

1. Înainte de a începe, asigurați-vă că aveți instalate componentele necesare.

Debian: aptitude install libdate-calc-perl mailutils

CentOS: yum install perl-Date-Calc mailx

2. Să purcedem!

Descărcăm: wget http://jimsun.linxnet.com/downloads/pflogsumm-1.1.3.tar.gz

Dezarhivăm: tar -zxvf pflogsumm-1.1.3.tar.gz

3. Copiem scriptul: cp pflogsumm-1.1.3/pflogsumm.pl /usr/local/bin/pflogsumm.pl

3′. Dacă rulați pe Debian, atunci trebuie să corectați numele fișierelor de logare a activităților postfix:

sed -i ‘s/maillog.0/mail.log.1/g’  /usr/local/bin/pflogsumm.pl

sed -i ‘s/maillog/mail.log/g’ /usr/local/bin/pflogsumm.pl

4. Redactăm crontab-ul: crontab -e

Adăugăm rularea scriptului pflogsumm.pl la urmă: /usr/local/bin/pflogsumm.pl -u 5 -h 5 –problems_first -d today /var/log/mail.log | mail -s „pflogsumm report `date`” root

După care obligatoriu lăsăm un rînd liber. Salvăm modificările.

5. Testăm dacă scriptul se execută fără erori – din consolă: /usr/local/bin/pflogsumm.pl -u 5 -h 5 –problems_first -d today /var/log/mail.log | mail -s „pflogsumm report `date`” root

Dacă nu apare niciun text – înseamnă că scriptul s-a executat cu succes.

6. Dacă nu aveți configurată readresarea scrisorilor de la utilizatorul root către un cont de e-mail valid, atunci puteți vedea e-mailurile direct din consolă, cu una din opțiunile: mail, mailx sau cone (pe asta v-o recomand, dacă nu este în sistem – se instalează cu: aptitude install cone) sau direct cu:  cat /var/spool/mail/root

În fiecare zi, la ora 23:59 veți primi un e-mail cu statistica detaliată pentru această zi.

Avantajul acestui script este că el doar prelucrează logurile mail.log(sau maillog), fără a se implica în funcționalitatea sistemului.

Transferul articolelor din extensia K2 în conținutul de bază Joomla

k2 - Joomla extension

Problematica

În versiunile vechi ale CMS Joomla, funcționalitatea de bază era destul de săracă, unele extensii ofereau posibilități mult mai interesante de prezentare a articolelor. Unul dintre acestea este K2. O dată cu versiunea a 2-a a CMS Joomla, interesul față de această extensie a dispărut, totuși unele site-uri elaborate pe atunci au continuat să o utilizeze. Unii pentru că nu au avut necesitatea de a face modificări, alții însă nu au putut să o facă. Dintre soluțiile găsite pe net, doar CMS2CMS poate transfera conținutul din K2 direct în Joomla sau în alt CMS. Dar acesta este cu plată.

După mai multe căutări pe net și încercări, am reușit să transfer conținutul din K2 în Joomla, iar apoi cu alt modul să-l transfer în WordPress. Totuși nu mi-a reușit să transfer imaginile și nu toate articolele au fost atribuite corect categoriile corespunzătoare, referitor la categorii nu sînt sigur dacă problema a fost în cazul K2=>Joomla sau Joomla=>Wordpress. Deci această soluție este parțială. Orice propuneri de îmbunătățire sînt binevenite!

Metodologia

În primul rînd se face o copie de rezervă a bazei de date (sau două, în locații diferite). Dacă vreți să mutați articolele la un site funcțional, atunci copiați baza de date și lucrați cu această copie.

Transferul se face prin instrucțiuni MySQL, copiind valorile din cîmpurile tabelului k2_items în cîmpurile tabelului content. Le puteți rula din consolă sau din meniul SQL a panoului phpMyAdmin, selectînd în prealabil baza de date. În phpMyAdmin, după autentificare, pur și simplu faceți click pe numele bazei de date din listă.

Dacă baza de date este prea mare, executarea instrucțiunilor ar putea cere mai mult timp decît permit setările web-serverului și veți primi o eroare, atunci va fi nevoie să executați comenzile din consolă. Pentru executare din consolă, urmați pașii:

Vă conectați la MySQL:
mysql -u numeutilizator -p
Introduceți parola utilizatorului bazei de date.
Afișați lista bazelor de date:
show databases;
Selectați pentru lucru baza de date necesară:
use numelebazeidedate;

Transferul propriu-zis din K2 în Joomla

Se face în două etape: mai întîi se copiază articolele, apoi categoriile.

Pentru articole executați:

INSERT INTO prefix_content (id, title, alias, catid, state, introtext, `fulltext`, created, created_by, modified, publish_up, featured, hits)
SELECT id, title, alias, catid, published, introtext, `fulltext`, created, created_by, modified, publish_up, featured, hits
FROM prefix_k2_items ;

Pentru categorii executați:

INSERT INTO prefix_categories (title, alias, published, catid)
SELECT name, alias, published, id
FROM prefix_k2_categories ;

În loc de „prefix_” indicați prefixul bazei de date. Dacă nu folosiți un prefix, eliminați acest prefix în toate cele patru poziții.

Transferul din Joomla în WordPress l-am făcut cu ajutorul modulului FG Joomla to WordPress.

Securizarea unui site WordPress

wordpress logo

Scop

WordPress reprezintă o platformă de gestionare a conținutului perfectă pentru un blog personal, un site de prezentare corporativ, portal informativ, magazin online, rețea socială, forum sau chiar scopuri mai complexe.

E un lucru foarte neplăcut cînd site-ul pe care îl aveți este spart și, în loc de interfața cunoscută, vă apare o muzică stranie cu inscripții deocheate gen „Hacked by #Bangladeshi Hacker”, iar urmările pot fi foarte triste – de la pierdere de timp, pînă la pierderea irecuperabilă a site-ului. Același rezultat îl pot avea și alte cauze: ștergerea sau modificarea datelor de către utilizator, defecțiunea serverului de găzduire, ne-prelungirea la timp a serviciul de găzduire și ștergerea lui automată, erori în timpul actualizării sistemului de administrare a conținutului (CMS) sau a modulelor, etc.

Pentru a preveni sau a minimaliza daunele cauzate de aceste și alte probleme, este nevoie DIN TIMP de a lua anumite măsuri de securitate. Să le analizăm pe rînd.

Chestiuni preliminare

Înainte de a lansa un site, trebuie să decideți unde va fi găzduit. Când veți alege un provider, atrageți atenția la mai multe aspecte:

  • reputația prestatorului de servicii;
  •  de cît timp activează;
  • dacă are servere proprii sau este doar un reseller;
  • modul de oferire a asistenței tehnice și monitorizarea serverelor;
  • disponibilitatea serviciilor adiționale și a setărilor personalizate pentru găzduire;
  • limitele de utilizare a resurselor și posibilitățile de mărire a pachetului de găzduire (în caz că site-ul dumneavoastră va cunoaște o creștere vertiginoasă a popularității);
  • locația serverului (dacă site-ul dumneavoastră se adresează publicului din Republica Moldova, ar fi indicat ca și găzduirea să fie în Moldova sau într-o țară de aproape – România, Germania); etc.
  • condițiile legale de prestare a serviciilor;

Un provider mare, în majoritatea cazurilor, are sistemul complet automatizat, multiple posibilități de plată. Un provider mic va fi mult mai flexibil și mai mult orientat spre client, dacă prestatorul este un antreprenor individual – aveți posibilitatea de a comunica direct cu persoana responsabilă.

Relația cu cel care va elabora site-ul dumneavoastră este și ea foarte importantă. Înainte de a începe orice lucrări, trebuie să vă înțelegi asupra sarcinilor ce urmează a fi realizate, cît va costa, cît timp va dura și ce va include elaborarea, cum veți realiza schimbările ulterioare (erori apărute sau modificări în principiul de lucru) și cît vor costa. În caz că persoana sau compania ce vă construiește site-ul nu va asigura întreținerea lui ulterioară, identificați o persoana căreia aceștia îi vor explica modul de lucru, de adăugare a materialelor și alte funcționalități ale site-ului.

Dacă cunoștințele dumneavoastră nu sînt suficiente pentru a gestiona un site WordPress, găsiți un specialist. Acesta va putea să vă ajute atunci cînd veți avea nevoie și va putea asigura actualizarea sistemului.

Măsuri de securitate

Pentru a minimaliza pericolele ce țin de funcționarea site-ului, este nevoie să luați în calcul anumite măsuri de securitate:

– asigurați-vă că providerul efectuează copii de rezervă în regim automat, le stochează în diferite locații, aflați cît timp sînt păstrate și în ce mod se poate face restabilirea;
– dacă nu sînteți sigur de gestionarea copiilor de rezervă de către prestator, sau în cazul cînd serviciul nu presupune copiere de rezervă – efectuați dumneavoastră periodic copii de rezervă;
– înainte de a face careva modificări în site (modificare de conținut, actualizări ale motorului și a modulelor adiționale) – faceți o copie de rezervă;
– folosiți o parolă complexă (minim 8 caractere, litere mari și mici, cifre și caractere speciale, evitați cuvintele de dicționar) pe care să o schimbați periodic;
– nu folosiți în calitate de nume de utilizator numele domeniului. Schimbați ID-ul utilizatorului în altul decît 1 ( se poate face cu ajutorul modului iThemes Security, care anterior se numea Better WP Security);
– setați pentru toate mapele drepturile de acces 755 și pentru fișiere 644 (prin FTP sau SSH);
– folosiți un modul pentru a ascunde adresa de autentificare în panoul de administrare (iThemes Security);
– setați blocarea automată după IP, pentru încercările de autentificare eșuate (iThemes Security);
– țineți actualizările sistemului și a modulelor la zi;
– nu folosiți module nesigure sau învechite;
– ștergeți modulele și temele care nu le folosiți;
– activați autentificarea în panoul de control doar prin HTTPS (dacă configurările serverului permit, redirecționare .htaccess sau iThemes Security);
– permiteți autentificarea în panoul de control doar de la anumite adrese IP – dacă nu e o piedică pentru activitatea site-ului (de acasă, de la serviciu, din alte locații sigure) și dacă providerul de internet vă oferă o adresă IP statică (.htaccess sau iThemes Security);
– modificați adresa de autentificare în panoul de control (iThemes Security), în loc de wp-admin și wp-login.php setați o adresă personală;
-monitorizați încercările de autentificare eșuate (iThemes Security) și blocați-le (WordPress Fail2ban, necesită setăți la nivel de sistem);
– monitorizați erorile 404;
– dacă panoul de administrare a găzduirii oferit de prestator vă permite, verificați periodic erorile care le generează web-serverul (apache, nginx) sau limbajul scripturilor (php, perl), cantitatea de trafic care o generează site-ul și încărcătura asupra serverului fizic;
– folosiți un serviciu de monitorizare a disponibilității serverului, de exemplu http://host-tracker.com/.

Ultima redactare: 24 noiembrie 2015.

Montarea adițională a dosarelor în Linux (Permanent mount and bind)

Montare permanentă a unui dosar. fstab bind

Utilizînd un sistem de operare Linux, poate apărea necesitatea de a monta un dosar în altă locație.

Scop

Principalele motive sînt două: Pentru a oferi unui dosar spațiu de pe altă partiție fără a modifica structura partițiilor sau pentru a oferi unui utilizator acces într-un dosar în care el nu are acces direct. În primul caz se face montarea adițională atunci cînd conținutul unui dosar depășește spațiul alocat inițial și nu se dorește redimensionarea partițiilor, care implică mai multe cunoștințe, riscuri și timp. În cazul al doilea, montarea adițională reprezintă o modalitate eficientă și comodă de a oferi acces unor utilizatori sau programe în dosarele spre care ei/ele nu au acces direct, spre exemplu acces pentru un utilizator FTP în alt dosar decît dosarul gazdă. Montarea poate fi curentă, ceea ce înseamnă că la repornirea calculatorului va dispărea, sau permanentă.

Realizare

Pentru montarea curentă, în consola linux executați cu drepturile de administrator o comandă de tipul:
mount –bind /locație/nouă/ /dosarul/sursă/
Unde: /dosarul/sursă/ – este locul real unde se va afla tot conținutul, iar /locație/nouă/ – este dosarul în care conținutul se va afișa repetat.

Pentru montare permanentă, în fișierul de configurare /etc/fstab se adaugă pentru fiecare montare adițională cîte o înregistrare de tipul:
/dosarul/sursă/ /locație/nouă/ bind rw,bind 0 0

Atenție!

Dacă conținutul /etc/fstab va fi incorect, sistemul de operare nu va putea să se încarce! Orice modificare care o faceți în una din locații se va răsfrînge asupra conținutului real! Dacă la același dosar cu conținut au acces mai mulți utilizatori, modificați drepturile de acces conform necesităților!

 

Modificarea numelui și a numelui de domeniu complet în linux (CentOS și Debian)

Cîteva instrucțiuni simple pentru a modifica și a verifica setarea numelui de domeniu și a numelui de domeniu complet (FQDN) în sistemele de operare linux CentOS și Debian.
Instrucțiunile pentru CentOS ar trebui să fie lucreze și pentru sistemele de operare Fedora, ArchLinux sau RedHat, iar instrucțiunile pentru Debian ar trebui să lucreze și pentru Ubuntu sau alte sisteme derivate.

hostname FQDN

CentOS

În fișierul /etc/hosts, se adaugă pentru IPv4 o înregistrare de tipul:
123.123.123.123 server1.domeniu.md server1
Sau, dacă se folosește șiIPv6, atunci se adaugă:
::1 server1.domeniu.md server1
Dacă serverul trebuie să fie accesibil după ambele adrese IP – atunci adăugați ambele înregistrări.

În /etc/sysconfig/network se modifică/adaugă:
HOSTNAME=server1

Pentru ca schimbările să fie aplicate este nevoie de a restarta serviciul de rețea, o puteți face prin comanda:
service network restart

Debian

În fișierul /etc/hostname se adaugă numele serverului, fără numele domeniului:
server1

În fișierul /etc/hosts, se adaugă pentru IPv4 o înregistrare de tipul:
123.123.123.123 server1.domeniu.md server1
Sau, dacă se folosește șiIPv6, atunci se adaugă:
::1 server1.domeniu.md server1
Dacă serverul trebuie să fie accesibil după ambele adrese IP – atunci adăugați ambele înregistrări.

Pentru a aplica schimbările, rulați comanda:
/etc/init.d/hostname.sh

Verificare

Pentru a vedea numele curent al serverului, folosiți comanda:
hostname
Pentru a vedea nume de domeniu complet (FQDN – Fully Qualified Domain Name), folosiți comanda:
hostname -f

Uneori după modificare nu veți putea vedea schimbările, pentru a rezolva această problemă este suficient să vă logați din nou. În unele cazuri schimbările se aplică doar la repornirea serverului.

Instrucțiunile pentru CentOS ar trebui să fie lucreze și pentru sistemele de operare Fedora, ArchLinux sau RedHat, iar instrucțiunile pentru Debian ar trebui să lucreze și pentru Ubuntu sau alte sisteme derivate.