Laborator 11 - Planificarea sarcinilor administrative

Configurarea infrastructurii de laborator

Înainte de începerea laboratorului rulați următoarele comenzi:

cd uso-lab
git pull
cd ~/uso-lab/labs/09-task-admin/lab-container/
./lab_prepare.sh cleanup

Înainte de începerea laboratorului rulați următoarele comenzi: cd ~/uso-lab/labs/09-task-admin/lab-container/, ./lab_prepare.sh install remote și ./lab_prepare.sh install ssh-server.

Dacă nu mai aveți spațiu pe disc, rulați comanda docker image prune --all.

Noi ca dezvoltatori software sau administratori de sisteme, avem nevoie de multă putere de procesare pentru a ne realiza obiectivele și accesibilitatea necesară pentru a folosi sistemele oricând, oricum.

Un avantaj la folosirea unei stații la distanță este faptul că este mereu disponibilă. Aceasta nu trebuie să fie oprită, nu are nevoie de restart, dacă ne deplasăm undeva, aceasta nu se schimbă cu nimic. De oriunde de oriunde l-ai accesa, vei avea la dispoziție sistemul la modul “Pickup and Play”.

Unele lucruri pe care vrem să le rezolvăm care necesită putere de procesare sunt compilarea programelor, antrenarea modelelor de machine learning, testarea la limită (stress testing) a aplicațiilor, sau simularea infrastructurilor complexe folosind mașini virtuale, rularea de servere complexe pentru anumite aplicații.

În mod obișnuit, sistemele care oferă multă putere de procesare nu vin în pachete compacte, ci acestea sunt sub formă de calculatoare de timp stații de lucru (workstation), servere, sau laptopuri grele. O altă abordare pentru a folosi un workstation este să obținem o mașină virtuală într-un cloud, cum ar fi AWS sau Microsoft Azure.

În același timp, nu este un lucru la îndemână pentru toți să lucreze pe astfel de sisteme din considerente de generare de căldură, consum de curent, spațiu la locul de muncă lipsă de mobilitate a sistemelor. Astfel, dacă vrem să lucrăm la o problemă care necesită multă putere de procesare, avem nevoie să fim în apropierea unui sistem care ne oferă multă putere de procesare. Acest lucru nu este mereu posibil din motive precum faptul că nu ai acces la locul de muncă sau că lucrezi într-un mediu la distanță.

În acest capitol prezentăm situația lucrului pe o stație la distanță. Cum putem să ne adaptăm modul de lucru pentru a folosi sisteme la care nu avem acces fizic și cum putem să monitorizăm și să folosim cât mai bine aceste sisteme.

Configurarea stației de lucru

Configurația mediului de lucru depinde de propriile gusturi și aplicațiile pe care le folosește fiecare și ne permite să fim mai eficienți.

Configurarea mediului de lucru este recomandată pentru a adapta sistemul la propriile nevoi. De exemplu, o persoană care va lucra foarte mult cu repository-uri de tip Git, probabil va avea nevoie de un prompt care să îi afișeze pe ce branch lucrează, astfel încât să gestioneze mai ușor branchurile. Aceste modificări au rolul de a reduce acțiunile repetitive pe care le facem sau de a pregăti aplicații pe care le vom folosi mai departe.

Această secțiune cuprinde recomandări de configurare a sistemului de la distanță. Au formă de sugestii, nu sunt obligații, pe baza cărora fiecare poate decide pentru configurarea propriului mediu de lucru.

Configurarea shellului

Primul aspect pe care îl vom modifica la mediul de lucru este shellul în care rulăm comenzi, deoarece acesta este cea mai folosită unealtă. Fie că că edităm cod, sau administrăm sisteme, acesta este locul unde rulăm comenzi.

Modificările la nivelul shellului se fac schimbând variabile de mediu sau rulând comenzi înainte de rularea efectivă a shellului.

Modificarea mediului shellului o realizăm într-un fișier de configurare. Vom folosi fișierul ~/.profile, deoarece acesta este citit și rulat de toate implementările de shell majorore, cum ar fi dash, csh, bash sau zsh, astfel oferă intercompatibilitate între shelluri.

Modificarea shellului predefinit

Ne dorim să modificăm shellul predefinit pe care îl folosește sistemul, deoarece fiecare implementare de shell oferă propriile funcționalități. De exemplu, fiecare dintre shellurile csh, bash și zsh implementează un mecanism de auto-completion diferit, astfel completarea se face în mod diferit atunci când apăsăm tasta Tab.

Pentru a modifica shellul predefinit al unui utilizator folosim comanda usermod cu opțiunea -s în felul următor:

student@uso:~$ sudo apt-get install zsh
[...]
student@uso:~$ sudo usermod -s /bin/zsh student
student@uso:~$ su - student
This is the Z Shell configuration function for new users,
[...]
--- Type one of the keys in parentheses --- 2
/home/student/.zshrc:15: scalar parameter HISTFILE created globally in function zsh-newuser-install
(eval):1: scalar parameter LS_COLORS created globally in function zsh-newuser-install
student@uso ~ % echo $SHELL
/bin/zsh

Rulând comanda de mai sus, am modificat shellul predefinit al utilizatorului student în /bin/zsh. Pentru verificare, ne-am autentificat ca utilizatorul student. La prima autentificare zsh ne-a întrebat ce fel de configurare vrem, iar noi am folosit opțiunea 2, pentru generarea automată a unei configurări. Am afișat valoarea variabilei SHELL pentru a afișa calea către shellul folosit.

Exercițiu: Modificarea shellului predefinit:

Modificați shellul predefinit al utilizatorului student cu shellul /bin/bash. Încercați să folosiți funcționalitatea de auto-complete. Ce observați?

Configurarea aliasurilor

Există comenzi pe care le rulăm frecvent. Totuși, unele comenzi sunt lungi și durează mult timp să le tastăm de fiecare dată atunci când vrem să le rulăm. Pentru a rezolva această problemă, putem folosi aliasuri. Un alias este o prescurtare pentru o comandă.

Vom folosi comanda alias pentru defini un alias.

student@uso:~$ alias gs="git status"
student@uso:~$ cd uso-lab/
student@uso:~/uso-lab$ gs
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
student@uso:~/uso-lab$ alias
[...]
alias gs='git status'
alias gti='git'
alias l='ls -CF'
alias la='ls -A'
alias ll='ls -alF'
alias ls='ls --color=auto'

Am definit aliasul gs pentru comanda git status și am verificat-o în repository-ul uso-lab.

Pentru a verifica ce aliasuri sunt definite, vom folosi comanda alias fără parametri.

Definirea de mai sus a unui alias nu este persistentă, ci acesta va fi definit cât timp shellul curent este deschis. Pentru a defini un alias în mod persistent, trebuie să îl definim, folosind comanda alias într-un fișier de configurare, cum ar fi .profile.

Exercițiu: Configurarea aliasurilor

  1. Configurați aliasul gcs pentru comanda git commit --signnoff.
  2. Configurați aliasul glog pentru comanda git log --oneline.

Modificarea dimensiunii istoricului de comenzi

Fișierul de istoric al unui shell este locul unde sunt salvate comenzile rulate într-un shell până la închiderea sesiunii de shell. Acest fișier este folositor pentru repetarea acțiunilor.

De exemplu, funcționalitatea de căutare inversă din shell bazată pe Ctrl+r caută în istoricul shellului, așa că este de preferat să avem un istoric complet în care să căutăm pentru a avea mai multe intrări în care să căutăm.

Pentru a mări dimensiunea istoricului shellului, este suficient să setăm variabila de mediu HISTSIZE într-un fișier de configurare. Vom folosi fișierul de configurare .profile din motivele enumerate mai sus, aflat în directorul home al utilizatorului student. Această modificare va fi valabilă doar pentru utilizatorul student.

student@uso:~$ echo HISTSIZE=20000 >> /home/student/.profile

Exercițiu: Modificarea dimensiunii istoricului de comenzi

Modificarea de mai sus nu este suficientă, deoarece aceasta schimbă doar dimensiunea istoricului din shell, care este salvat în fișierul de istoric la închiderea sesiunii de shell. La pornirea shellului, dimensiunea fișierului de istoric este concatenată folosind variabila HISTFILESIZE. Valoarea predefinită a acestei variabile este 500.

Faceți modificările necesare astfel încât fișierul de istoric să fie concatenat la 20000 de comenzi la pornirea shellului.

Configurarea promptului

Promptul este o sursă importantă de informații. Acesta ne poate oferi mai multă informație și ne eliberează din a rula anumite comenzi. Practic, noi putem obține mai mult informații rulând mai puține comenzi.

De exemplu, dacă lucrăm foarte des cu repository-uri de Git, vrem să avem un mod cât mai facil de a vedea pe ce branch lucrăm. Această informație poate fi adăugată în prompt.

Promptul shellului bash este setat folosind variabila PS1. Orice șir de caractere va fi scris în variabila PS1 și va fi afișat înainte de zona în care introducem comenzi. Dacă modificăm variabila PS1 vom vedea că promptul se modifică:

student@uso:~$ echo $PS1
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
student@uso:~$ PS1="president@white-house:~$ "
president@white-house:~$ hostname
uso
president@white-house:~$ id
uid=1000(student) gid=1000(student) groups=1000(student),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),120(lpadmin),131(lxd),132(sambashare),997(docker)
president@white-house:~$ 

După cum observăm în rezultatul primei comenzi rulate mai sus, valoarea variabilei PS1 este un șir de caractere complex, dar noi putem să îl suprascriem. Odată suprascrisă variabila PS1, promptul se schimbă în valoarea din variabilă. Totuși, am rulat comenzi de verificare pentru a vedea că utilizatorul cu care suntem autentificați este în continuare student și stația la care suntem conectați este uso

Putem să generăm propriul prompt complex folosind utilitare online. Recomandăm EZPrompt . Acest site are funcționalitatea de a genera un prompt modificat. Vrem să generăm un prompt de forma username@hostname:path_to_current_dir-git_branch. EZPrompt a generat următoarele comenzi pentru a modifica promptul, pe care le vom adăuga la finalul fișierului .profile:

# get current branch in git repo
function parse_git_branch() {
    BRANCH=`git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1/'`
    if [ ! "${BRANCH}" == "" ]
    then
        STAT=`parse_git_dirty`
        echo "[${BRANCH}${STAT}]"
    else
        echo ""
    fi
}
# get current status of git repo
function parse_git_dirty {
    status=`git status 2>&1 | tee`
    dirty=`echo -n "${status}" 2> /dev/null | grep "modified:" &> /dev/null; echo "$?"`
    untracked=`echo -n "${status}" 2> /dev/null | grep "Untracked files" &> /dev/null; echo "$?"`
    ahead=`echo -n "${status}" 2> /dev/null | grep "Your branch is ahead of" &> /dev/null; echo "$?"`
    newfile=`echo -n "${status}" 2> /dev/null | grep "new file:" &> /dev/null; echo "$?"`
    renamed=`echo -n "${status}" 2> /dev/null | grep "renamed:" &> /dev/null; echo "$?"`
    deleted=`echo -n "${status}" 2> /dev/null | grep "deleted:" &> /dev/null; echo "$?"`
    bits=''
    if [ "${renamed}" == "0" ]; then
        bits=">${bits}"
    fi
    if [ "${ahead}" == "0" ]; then
        bits="*${bits}"
    fi
    if [ "${newfile}" == "0" ]; then
        bits="+${bits}"
    fi
    if [ "${untracked}" == "0" ]; then
        bits="?${bits}"
    fi
    if [ "${deleted}" == "0" ]; then
        bits="x${bits}"
    fi
    if [ "${dirty}" == "0" ]; then
        bits="!${bits}"
    fi
    if [ ! "${bits}" == "" ]; then
        echo " ${bits}"
    else
        echo ""
    fi
}
export PS1="\u@\h:\w-\`parse_git_branch\` "

Pornind un nou shell, vedem că promptul s-a schimbat, acum nu mai este colorat. Când schimbăm directorul curent într-un repository Git, în prompt va apărea și branch-ul pe care este setată replica repository-ului

student@uso:~- cd uso-lab/
student@uso:~/uso-lab-[master !?] check-language-support ^C

Exercițiu: Configurarea promptului

Se întâmplă ca atunci când lucrăm cu ierarhii de fișiere cu multe directoare, să nu încapă comenzile pe un singur rând. Acest lucru este deranjant, deoarece comenzile devin greu de urmărit.

Pentru a rezolva această problemă, vrem să avem promptul pe un rând și spațiul unde introducem textul pe următorul rând.

Modificați promptul astfel încât comenzile rulate să apară pe următorul rând față de prompt.

Gestionarea spațiului de stocare partajat

Pentru a parcurge această secțiune este recomandat să descărcați ultima versiune a respository-ului laboratorului. Pentru a descărca ultima versiune a repository-ului, rulați comanda git pull în directorul ~/uso-lab/labs/09-task-admin/lab-container/.

Infrastructura laboratorului este bazată pe containere Docker ale căror imagini vor fi generate pe propriul calculator. Dacă nu aveți deja instalat Docker Engine pe sistem, scriptul ~/uso-lab/labs/09-task-admin/lab-container/lab_prepare.sh vă va instala aplicația.

După ce ați terminat de lucrat, vă recomandăm să opriți containerele rulând comanda ./lab_prepare.sh delete în directorul ~/uso-lab/labs/09-task-admin/lab-container/.

O componentă importantă a mediului de lucru este spațiul de stocare. De multe ori vom avea nevoie sa accesam si sa editam fisiere aflate pe o alta statie.

Stocare partajată folosind SSHFS

Pentru rularea acestui demo, rulați în directorul ~/uso-lab/labs/09-task-admin/lab-container/ comanda ./lab_prepare.sh install remote și comanda ./lab_prepare.sh install ssh-server. Pentru a ne conecta la infrastructura pentru această secțiune, vom folosi comanda ./lab_prepare.sh connect local.

SSHFS este o soluție de stocare partajată care permite montarea unui sistem de fișiere care nu este legat fizic la stația local, ci se folosește de protocolul SSH pentru a transmite operațiile asupra fișierelor prin rețea către un sistem de fișiere conectat prin rețea.

Avantajul folosirii SSHFS este că nu necesită descărcarea sistemului de fișiere de la distanță, deci nu duce la duplicarea fișierelor. Dezavantajul acestei abordări este că dacă pierdem conexiunea la sistemul de fișiere de la distanță, nu mai avem acces la fișiere.

Montarea temporară a unui sistem de fișiere

Pentru a monta sistemul de fișiere de pe un alt sistem, vom folosi comanda sshfs

root@local:~# ls /mnt/

root@local:~# sshfs root@10.11.11.2:/ /mnt/
The authenticity of host '10.11.11.2 (10.11.11.2)' can't be established.
ECDSA key fingerprint is SHA256:xV1orHYj4fhkc5HE91sfh8QhaVqke/AEMa8mYI423HY.
Are you sure you want to continue connecting (yes/no)? yes
root@10.11.11.2's password:

root@local:~# df -h
Filesystem         Size  Used Avail Use% Mounted on
overlay             16G   14G  539M  97% /
tmpfs               64M     0   64M   0% /dev
tmpfs              2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/sda5           16G   14G  539M  97% /etc/hosts
shm                 64M     0   64M   0% /dev/shm
root@10.11.11.2:/   16G   14G  539M  97% /mnt

root@local:~# ls /mnt/
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

Comanda de mai sus a montat ierarhia de fișiere cu rădăcina în directorul / de pe sistemul de la adresa IP 10.11.11.2 în directorul /mnt de pe stația locală, cu numele local, autentificându-se ca utilizatorul root.

Am folosit comanda df pentru a afișa informații despre toate sistemele de fișiere montate pe stația locală. Observăm că pe ultima linie apare conexiunea către stația de la adresa 10.11.11.2.

Sintaxa comenzii sshfs se aseamănă cu sintaxa comenzii scp.

Acest mod de montare a sistemului de fișiere este temporară. Atunci când vom opri stația, sistemul de fișiere va fi demontat.

Exercițiu: Montarea temporară a unui sistem de fișiere

  1. Montați temporar sistemul de fișiere cu rădăcina în directorul / de pe stația 10.11.11.2 în directorul /mnt/vol1.
  2. Montați temporar sistemul de fișiere cu rădăcina în directorul /home/student de pe stația 10.11.11.2 în directorul /mnt/vol2.

Montarea persistentă a unui sistem de fișiere

Deoarece nu ne dorim să rulăm comanda sshfs atunci când vrem să folosim un sistem de fișiere la distanță, vrem să montăm persistent sistemul de fișiere de la distanță, astfel încât această montare să persiste după oprirea stației locale.

Ca să montăm persistent sistemul de fișiere avem nevoie să copiem cheia SSH pe stația de la distanță, deoarece montarea se va face în mod neinteractiv, deci nu vom avea posibilitatea de a introduce parola, așa cum am descoperit în laboratorul Configurarea avansată a sistemului.

Pentru a monta persistent sistemul de fișiere, vom scrie o intrare în fișierul /etc/fstab, care va conține detalii despre sistemul de fișiere pe care vrem să îl montăm. Pentru a monta sistemul de fișiere / de pe sistemul de la adresa IP 10.11.11.2 în directorul /mnt de pe stația locală, autentificându-ne ca utilizatorul root`, vom folosi următoarele comenzi:

root@local:~# ssh-keygen
[...]
root@local:~# ssh-copy-id root@10.11.11.2
[...]
root@local:~# echo "root@10.11.11.2:/  /mnt  fuse.sshfs  defaults  0  0" >> /etc/fstab

root@local:~# mount -a

root@local:~# df -h
Filesystem         Size  Used Avail Use% Mounted on
overlay             16G   14G  539M  97% /
tmpfs               64M     0   64M   0% /dev
tmpfs              2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/sda5           16G   14G  539M  97% /etc/hosts
shm                 64M     0   64M   0% /dev/shm
root@10.11.11.2:/   16G   14G  539M  97% /mnt

Am scris în fișierul /etc/fstab folosind comanda echo, iar pentru a monta sistemul de fișiere am folosit comanda mount cu opțiunea -a pentru montarea sistemelor de fișiere descrise în fișierul /etc/fstab.

Atenție!:

În mod normal am scrie în fișierul /etc/fstab folosind un editor de text. Vă recomandăm să nu scrieți în fișiere critice sistemului folosind redirectări, deoarece orice greșeală poate șterge conținutul fișierului.

Exercițiu: Montarea persistentă a unui sistem de fișiere

  1. Montați persistent sistemul de fișiere cu rădăcina în directorul / de pe stația 10.11.11.2 în directorul /mnt/vol1.
  2. Montați persistent sistemul de fișiere cu rădăcina în directorul /home/student de pe stația 10.11.11.2 în directorul /mnt/vol2.

Stocare partajată folosind aplicații online

SSHFS nu este o soluție bună pentru a face backup fișierelor deoarece, existând o singură replică, ștergerea locală a unui fișier duce la ștergerea sa și de pe stația remote și, astfel, la pierderea sa. Pe lângă aceasta, dacă stația locală are conexiune slabă la Internet, accesul la fișiere este greoi și neresponsiv. Suplimentar, trebuie configurată o conexiune SSH, care poate necesita la rândul ei existența unui tunel etc.

O alternativă la folosirea SSHFS sunt soluții cum ar fi GoogleDrive, Dropbox, ownCloud sau One Drive. Aceste soluții stochează o replică a fișierului pe toate calculatoarele autentificate de pe un anumit cont. Un alt avantaj al acestora este că oferă suport pentru controlul versiunilor pentru a șterge modificarea anterioară. Cu dezavantajul că trebuie configurate și cu riscul apariției conflictelor la modificări simultane pe noduri diferite. Și cu dezavantajul că acum informația este duplicată: dublu spațiu ocupat și pot apărea conflicte la modificări.

Stocarea partajată folosind Dropbox

Pentru rularea acestui demo vom folosi direct mașina virtuală uso.

Dropbox este o soluție care se folosește de un server în Internet care stochează fișierele, ca apoi acestea să fie replicate pe fiecare calculator client.

Este necesară crearea și activarea un cont pentru a folosi serviciul Dropbox.

Dropbox oferă o aplicație care rulează în linie de comandă pe care o vom descărca pentru a sincroniza sistemul de fișiere de pe serverele Dropbox într-un director local.

Vom descărca aplicația Dropbox folosind comanda wget și o vom instala folosind comanda dpkg împreună cu parametrul -i.

student@uso:~$ wget https://www.dropbox.com/download?dl=packages/ubuntu/dropbox_2020.03.04_amd64.deb -O dropbox.deb
[...]
student@uso:~$ sudo dpkg -i dropbox.deb 
Starting Dropbox...
Dropbox is the easiest way to share and store your files online. Want to learn more? Head to https://www.dropbox.com/

In order to use Dropbox, you must download the proprietary daemon. [y/n] y
[...]
student@uso:~$ dropbox start
To link this computer to a Dropbox account, visit the following url:
https://www.dropbox.com/cli_link_nonce?nonce=ffd7d648a2ca2302d1177c0c389e87bd

Observație

Am folosit opțiunea -O a comenzii wget pentru a salva fișierul descărcat cu numele dropbox.deb.

Pentru a instala ultimele componente ale clientului Dropbox este necesar să rulăm comanda dropbox start -i. După ce am ponit aplicația, este necesar să înregistrăm stația online la contul nostru. Vom face acest lucru accesând linkul afișat de aplicație.

Exercițiu: Stocarea partajată folosind Dropbox

Pentru rezolvarea acestui exercițiu, rulați în directorul ~/uso-lab/labs/09-task-admin/lab-container/ comanda ./lab_prepare.sh install dropbox. Pentru a ne conecta la infrastructura pentru această secțiune, vom folosi comanda ./lab_prepare.sh connect dropbox.

  1. Conectați-vă la stația dropbox și porniți aplicația Dropbox pe aceasta.
  2. Creați un fișier numit hello.txt în directorul ~/Dropbox, partajat de cele două mașini. Scrieți în fișier mesajul Hello from remote pe stația dropbox. Verificați că există fișierul hello.txt în directorul ~/Dropbox pe stația uso.

Configurarea și administrarea serviciilor

Scopul serviciilor este să ruleze în continuu și să primească cereri de la aplicații client, cum ar fi un client SSH, și să răspundă la aceste cereri. Serviciile sunt aplicații care rulează în continuu pe stație, spre deosebire de comenzi, cum ar fi find sau ls, care rulează cât timp se execută comanda. Deoarece ne dorim să avem majoritatea timpului conectivitate la mașină, sau ne dorim să avem acces la paginile web folosite, serverele rulează fără oprire și servesc cereri venite de la clienți. Un sever / serviciu este oprit explicit de utilizator prin comenzi specifice sau este oprit la oprirea sistemului. Fără o intervenție explicită și fără oprirea sistemului, un server / serviciu va rula nedefinit.

Vrem să pornim și să configurăm servicii instalate în sistem, precum:

  • un server web;
  • un server SSH, pentru a ne conecta la stație;
  • un serviciu care ține un tunel SSH deschis către stație

Avem nevoie de o interfață unică, cu o sintaxă minimală, care ne permite să gestionăm serviciile pe sistem, și care ne permite sa generăm noi propriile servicii.

Lucrul cu serviciile în Linux

Comanda folosită pentru gestionarea serviciilor este systemctl. Aceasta se regăsește pe majoritatea distribuțiilor moderne de Linux.

Verificarea stării unui serviciu

Atunci când instalăm o aplicație care rulează sub forma unui serviciu, vom putea să îi verificăm starea folosind comanda systemctl status.

student@uso:~$ systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2021-01-09 04:22:11 EET; 1min 17s ago
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 639 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 657 (sshd)
      Tasks: 1 (limit: 4656)
     Memory: 4.8M
     CGroup: /system.slice/ssh.service
             └─657 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups

ian 09 04:22:11 uso systemd[1]: Starting OpenBSD Secure Shell server...
ian 09 04:22:11 uso sshd[657]: Server listening on 0.0.0.0 port 22.
ian 09 04:22:11 uso sshd[657]: Server listening on :: port 22.
ian 09 04:22:11 uso systemd[1]: Started OpenBSD Secure Shell server.
ian 09 04:23:25 uso sshd[1821]: Accepted password for student from 192.168.56.1 port 33714 ssh2
ian 09 04:23:25 uso sshd[1821]: pam_unix(sshd:session): session opened for user student by (uid=0)

Mai sus am afișat starea serviciului SSH. Observăm că acesta este activ și putem urmări ce procese a generat și ce mesaje de diagnosticare afișează.

Programul systemd se ocupă de pornirea, oprirea și gestionarea serviciilor folosite în sistem pe baza unor fișiere numite fișiere unitate. Fișierul care gestionează serviciul SSH este /lib/systemd/system/ssh.service. Îl putem identifica din rezultatul comenzii systemctl status.

Atunci când un serviciu este instalat, acesta vine la pachet cu fișierul cu extensia .service cu care acesta va fi gestionat de systemd, după cum putem vedea în rezultatul comenzii de mai jos:

student@uso:~$ sudo apt install ntp
[...]
Setting up ntp (1:4.2.8p12+dfsg-3ubuntu4) ...
Created symlink /etc/systemd/system/network-pre.target.wants/ntp-systemd-netif.path → /lib/systemd/system/ntp-systemd-netif.path.
Created symlink /etc/systemd/system/multi-user.target.wants/ntp.service → /lib/systemd/system/ntp.service.
ntp-systemd-netif.service is a disabled or a static unit, not starting it.
[...]

Serviciul ntp este folosit pentru sincronizarea ceasului cu surse precise de timp din Internet. Acesta este un serviciu important pentru buna funcționare a aplicațiilor în Internet, deoarece o configurare a timpului pentru o stație poate duce la o funcționare incorectă a acesteia în comunicare.

Exercițiu: Afișarea stării serviciilor

Afișați starea serviciului thermald, care gestionează senzorii de temperatură ai sistemului.

Oprirea unui serviciu

Pentru a opri un serviciu vom folosi comanda systemctl stop în felul următor:

student@uso:~$ sudo netstat -tlpn
[sudo] password for student: 
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      501/systemd-resolve 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      4425/sshd: /usr/sbi 
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      541/cupsd           
tcp6       0      0 :::22                   :::*                    LISTEN      4425/sshd: /usr/sbi 
tcp6       0      0 ::1:631                 :::*                    LISTEN      541/cupsd           
student@uso:~$ sudo systemctl stop ssh
[sudo] password for student:
student@uso:~$ sudo systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: e>
     Active: inactive (dead) since Sat 2021-01-09 04:58:28 EET; 9s ago
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 640 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
    Process: 660 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=0/>
   Main PID: 660 (code=exited, status=0/SUCCESS)

ian 09 04:57:29 uso systemd[1]: Starting OpenBSD Secure Shell server...
ian 09 04:57:29 uso sshd[660]: Server listening on 0.0.0.0 port 22.
ian 09 04:57:29 uso sshd[660]: Server listening on :: port 22.
ian 09 04:57:29 uso systemd[1]: Started OpenBSD Secure Shell server.
ian 09 04:58:28 uso sshd[660]: Received signal 15; terminating.
ian 09 04:58:28 uso systemd[1]: Stopping OpenBSD Secure Shell server...
ian 09 04:58:28 uso systemd[1]: ssh.service: Succeeded.
ian 09 04:58:28 uso systemd[1]: Stopped OpenBSD Secure Shell server.

Pentru a verifica dacă mai funcționează serviciul SSH vom folosi comanda netstat pentru a verifica dacă mai ascultă serverul SSH pe portul 22.

student@uso:~$ sudo netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      501/systemd-resolve
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      541/cupsd
tcp6       0      0 ::1:631                 :::*                    LISTEN      541/cupsd

Observăm că nu ascultă niciun program pe portul 22.

Recapitulare: Afișarea stării serviciilor

Afișați starea serviciului ssh.

Pornirea unui serviciu

Pornirea unui serviciu se face folosind comanda systemctl start în felul următor:

student@uso:~$ systemctl start ssh
student@uso:~$ systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2021-01-09 05:05:30 EET; 2min 30s ago
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 4408 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 4425 (sshd)
      Tasks: 1 (limit: 4656)
     Memory: 3.4M
     CGroup: /system.slice/ssh.service
             └─4425 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups

ian 09 05:05:30 uso systemd[1]: Starting OpenBSD Secure Shell server...
ian 09 05:05:30 uso sshd[4425]: Server listening on 0.0.0.0 port 22.
ian 09 05:05:30 uso sshd[4425]: Server listening on :: port 22.
ian 09 05:05:30 uso systemd[1]: Started OpenBSD Secure Shell server.
ian 09 05:05:54 uso sshd[4477]: Accepted password for student from 192.168.56.1 port 34852 ssh2
ian 09 05:05:54 uso sshd[4477]: pam_unix(sshd:session): session opened for user student by (uid=0)

Dacă serviciul nu pornește cu succes, aceasta va afișa un mesaj de avertizare.

Repornirea unui serviciu

Pe parcursul rulării serviciilor pe un sistem, vom dori să schimbăm configurația unui serviciu sau să adăugăm parametri de rulare în plus. Majoritatea aplicațiilor citesc fișierele de configurare o singură dată, atunci când sunt pornite, deci orice modificare ulterioară a fișierelor de configurare nu va fi sesizată de serviciu. Din acest motiv, avem nevoie să repornim servicii.

De exemplu, vrem să permitem utilizatorilor să se autentifice ca utilizatorul root pe sistemul nostru. Acest lucru este dezactivat în mod predefinit de serviciu din motive de securitate.

student@uso:~$ ssh root@localhost
root@localhost's password: 
Permission denied, please try again.
[...]

Observăm că inițial nu puteam să ne conectăm la mașina locală ca utilizatorul root, cu toate că introduceam parola corectă.

student@uso:~$ sudo su -c 'echo "PermitRootLogin yes" >> /etc/ssh/sshd_config'
student@uso:~$ systemctl restart ssh
student@uso:~$ ssh root@localhost
root@localhost's password:
[...]
root@uso:~#

Pentru a face acest lucru, avem nevoie să reconfigurăm serviciul SSH. Odată ce am adăugat opțiunea PermitRootLogin yes în fișierul de configurare al serviciului și am repornit serviciului, am reușit să ne autentificăm ca utilizatorul root.

Pornirea unui serviciu la startup

Atunci când configurăm un sistem și vrem să definim servicii care rulează pe el, ne dorim ca serviciile să fie setup and forget, să nu fie necesar să le supraveghem și să le monitorizăm prea mult. Un mod de a ne ușura lucrul cu serverul este pornirea serviciilor la startup, ca să nu fie nevoie sa intervenim noi după secvența de pornire a sistemului, ca să le pornim de mână, folosind comanda systemctl start

Putem să vedem dacă un sistem pornește automat la startup din rezultatul comenzii systemctl status pe linia care începe cu Loaded:. Dacă rezultatul conține șirul de caractere enabled, atunci serviciul pornește la startup, iar dacă aceasta conține șirul disabled, atunci serviciul nu va porni la startup.

Pentru a dezactiva un serviciu la startup vom folosi comanda systemctl disable în felul următor:

student@uso:~$ sudo systemctl disable ntp
Synchronizing state of ntp.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable ntp
Removed /etc/systemd/system/multi-user.target.wants/ntp.service.
student@uso:~$ sudo systemctl status ntp
    ● ntp.service - Network Time Service
     Loaded: loaded (/lib/systemd/system/ntp.service; disabled; vendor preset: enabled)
     Active: active (running) since Sat 2021-01-09 05:18:49 EET; 27min ago
       Docs: man:ntpd(8)
   Main PID: 9756 (ntpd)
      Tasks: 2 (limit: 4656)
     Memory: 1.3M
     CGroup: /system.slice/ntp.service
             └─9756 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 127:134

ian 09 05:18:55 uso ntpd[9756]: Soliciting pool server 185.173.16.132
ian 09 05:24:31 uso ntpd[9756]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
ian 09 05:28:41 uso ntpd[9756]: 91.189.91.157 local addr 10.0.2.15 -> <null>
ian 09 05:29:00 uso ntpd[9756]: 85.204.240.2 local addr 10.0.2.15 -> <null>
ian 09 05:29:04 uso ntpd[9756]: 188.213.49.35 local addr 10.0.2.15 -> <null>
ian 09 05:29:05 uso ntpd[9756]: 86.124.75.41 local addr 10.0.2.15 -> <null>
ian 09 05:29:08 uso ntpd[9756]: 85.204.240.1 local addr 10.0.2.15 -> <null>
ian 09 05:29:09 uso ntpd[9756]: 195.135.194.3 local addr 10.0.2.15 -> <null>
ian 09 05:29:52 uso ntpd[9756]: 91.189.89.198 local addr 10.0.2.15 -> <null>
ian 09 05:38:03 uso ntpd[9756]: 93.190.144.28 local addr 10.0.2.15 -> <null>

Observăm că pe linia care conține șirul de caractere Loaded, mesajul este disabled, dar serviciul funcționează în continuare.

Pentru a activa un serviciu la startup vom folosi comanda systemctl enable:

student@uso:~$ sudo systemctl enable ntp
Synchronizing state of ntp.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable ntp
Created symlink /etc/systemd/system/multi-user.target.wants/ntp.service → /lib/systemd/system/ntp.service.
student@uso:~$ sudo systemctl status ntp
● ntp.service - Network Time Service
     Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2021-01-09 05:18:49 EET; 30min ago
       Docs: man:ntpd(8)
   Main PID: 9756 (ntpd)
      Tasks: 2 (limit: 4656)
     Memory: 1.3M
     CGroup: /system.slice/ntp.service
             └─9756 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 127:134

ian 09 05:18:55 uso ntpd[9756]: Soliciting pool server 185.173.16.132
ian 09 05:24:31 uso ntpd[9756]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
ian 09 05:28:41 uso ntpd[9756]: 91.189.91.157 local addr 10.0.2.15 -> <null>
ian 09 05:29:00 uso ntpd[9756]: 85.204.240.2 local addr 10.0.2.15 -> <null>
ian 09 05:29:04 uso ntpd[9756]: 188.213.49.35 local addr 10.0.2.15 -> <null>
ian 09 05:29:05 uso ntpd[9756]: 86.124.75.41 local addr 10.0.2.15 -> <null>
ian 09 05:29:08 uso ntpd[9756]: 85.204.240.1 local addr 10.0.2.15 -> <null>
ian 09 05:29:09 uso ntpd[9756]: 195.135.194.3 local addr 10.0.2.15 -> <null>
ian 09 05:29:52 uso ntpd[9756]: 91.189.89.198 local addr 10.0.2.15 -> <null>
ian 09 05:38:03 uso ntpd[9756]: 93.190.144.28 local addr 10.0.2.15 -> <null>

Observăm că pe linia care conține șirul de caractere Loaded, mesajul s-a schimbat în enabled.

Configurarea unui serviciu

În majoritatea cazurilor, serviciile sunt configurate prin fișiere de configurare. Acestea se pot găsi în mai multe locuri:

  • /etc/default/, unde sunt fișiere care permit modificarea opțiunilor de rulare a unei comenzi, ca și cum am adăuga noi opțiuni la rularea unei comenzi. Aceste fișiere sunt citite de systemd, înainte să pornească serviciul;
  • directorul /etc/nume_serviciu/ , unde se află fișierele de configurare sau direct fișierul /etc/nume_serviciu. Aceste fișiere sunt citite și interpretate de servici. De exemplu, pentru configurarea serviciului NTP, există fișierul /etc/ntp.conf, iar pentru configurarea serviciului SSH folosim fișierele din directorul /etc/ssh/.

Exerciții: Gestiunea serviciilor

  1. Ordered List ItemConfigurați serviciul SSH pentru a permite autentificarea ca utilizatorul root folosind numai autentificare bazată pe chei.
  2. Instalați serviciul vsftpd. Acesta este un serviciu de transfer de fișiere.Realizați modificările necesare astfel încât acest serviciu să NU pornească la startup; Dezactivați funcționalitatea bazată pe IPv6 a serviciului. Hint: listen_ipv6, listen. Asigurați-vă că serviciul rulează. Acest serviciu ascultă pe portul 21.

Cuprins

uso/laboratoare/ac/laborator-11.txt · Last modified: 2021/10/12 19:44 (external edit)
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0