certificazione LPIC

Area di discussione libera.

Moderatore: Staff

Regole del forum
1) Rispettare le idee altrui.
2) Evitare le offese dirette.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Meskalamdug
Iper Master
Iper Master
Messaggi: 3918
Iscritto il: ven 14 mag 2004, 0:00

Re: certificazione LPIC

Messaggio da Meskalamdug »

ZeroUno ha scritto:
brg ha scritto:Ma, guarda, è la stessa ragione del successo di System V in ambiente Linux: più difficile da gestire per l'utente, molto più facile da configurare per le applicazioni.
Questo è vero (anche se systemV non era difficile per l'utente).
Più difficile è meno la gente ci mette le mani e meno i tool devono verificare che non hai fatto casini.

Ultimamente systemd ha sostituito parzialmente anche il syslog (c'è running rsyslogd ma alcune cose sono loggate solo su systemd).
A me continua a ricordare tantissimo solaris smf,dove hai due log(sic!) il classico syslog
e i log dei servizi gestiti da SMF.

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5284
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: certificazione LPIC

Messaggio da ZeroUno »

Meskalamdug ha scritto:Io sono abituato a modificare /etc/named.conf e dare rndc reload,non è più semplice
che editare degli xml con svccfg?
noo, named nooo, ti prego, non me lo potete toccare così !!!!!! :(
per fortuna a solaris 11 ormai ci pensano i miei colleghi. io mi limito ad usare qualche server solaris 10 già installato e configurato da anni; in questi giorni stiamo dismettendo un po' di solaris 9 a favore di linux.

Intanto ho passato anche il secondo modulo (ma era molto facile). La prossima settimana cominciano le cose serie... tra cui bind ;). Speriamo che non facciano scherzi!

In sede ho visto che in questi giorni hanno messo in piedi una macchina con redhat 7 (e quindi systemd) perchè pare ci sia un servizio nuovo che stiamo testando che lo richiede (redhat 7, non systemd).
Speriamo bene.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Meskalamdug
Iper Master
Iper Master
Messaggi: 3918
Iscritto il: ven 14 mag 2004, 0:00

Re: certificazione LPIC

Messaggio da Meskalamdug »

Il terzo modulo della LPIC è il più complesso,io 5 anni fa l'ho presa(devo aggiornarla entro marzo)
e trattava sopratutto ldap che però doveva essere usato in ambiente misto windows-linux(o meglio
ad+linux).
Adesso nella pagina di lpic sembra che abbiano aggiunto samba4 come argomento principale della lpic-3

Meskalamdug
Iper Master
Iper Master
Messaggi: 3918
Iscritto il: ven 14 mag 2004, 0:00

Re: certificazione LPIC

Messaggio da Meskalamdug »

ZeroUno ha scritto:
Meskalamdug ha scritto:Io sono abituato a modificare /etc/named.conf e dare rndc reload,non è più semplice
che editare degli xml con svccfg?
noo, named nooo, ti prego, non me lo potete toccare così !!!!!! :(
per fortuna a solaris 11 ormai ci pensano i miei colleghi. io mi limito ad usare qualche server solaris 10 già installato e configurato da anni; in questi giorni stiamo dismettendo un po' di solaris 9 a favore di linux.

Intanto ho passato anche il secondo modulo (ma era molto facile). La prossima settimana cominciano le cose serie... tra cui bind ;). Speriamo che non facciano scherzi!

In sede ho visto che in questi giorni hanno messo in piedi una macchina con redhat 7 (e quindi systemd) perchè pare ci sia un servizio nuovo che stiamo testando che lo richiede (redhat 7, non systemd).
Speriamo bene.
Una curiosità : ma solaris9 ha ancora gli aggiornamenti di sicurezza oracle?

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5284
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: certificazione LPIC

Messaggio da ZeroUno »

E' una vita che non faccio aggiornamenti di sicurezza su sistemi Sun. L'idea che se una cosa funziona non si tocca è sempre valida (mi è capitato tante volte di dover rollbackare il patching).
Ho i miei dubbi che oracle scriva ancora patch per solaris 9 (che usavo nel 2006), ed io ho ancora qualche solaris 8.
L'ultima volta che che ho patchato un sistema sun è stato 10 anni fa con solaris 8, dove ogni anno aggiornavamo tutto il parco macchine (quando avevo finito era già ora di ripatchare i primi)!
Come dicevo dove sono ora io non mi occupo strettamente dei sistemi solaris quanto piuttosto le applicazioni che ci girano sopra; su quei pochi che uso se c'è un problema lo so risolvere, ma se si va oltre c'è un gruppo dedicato.
Fin dove possibile stiamo cercando di farli fuori. Infatti non ho ancora capito perchè abbiamo cominciato a mettere solaris 11 invece di convertire l'applicazione (non so quale) per farla girare su linux.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

hashbang
Packager
Packager
Messaggi: 1980
Iscritto il: ven 4 giu 2010, 10:27
Nome Cognome: Luca De Pandis
Distribuzione: macOS Catalina
Località: Lecce / Bergamo / Milano
Contatta:

Re: certificazione LPIC

Messaggio da hashbang »

Meskalamdug ha scritto:A me continua a ricordare tantissimo solaris smf,dove hai due log(sic!) il classico syslog
e i log dei servizi gestiti da SMF.
In realtà journald non ha bisogno di syslogd.
syslogd viene usato in contemporanea in quanto nell'enterprise si è ancora restii a passare al logging binario.
E di conseguenza per ora si fa redirect del log di sistema a syslogd.

Tuttavia ci sono stati diversi bug. Uno su tutti il bug su SUSE che faceva schizzare a caso la CPU al 100%.
Detto questo, il log plain-text non è una configurazione attivamente supportata. Anzi, gli sviluppatori di systemd spingono per l'uso esclusivo di journald e del log binario.

In ogni caso, il redirect su syslog non coinvolge affatto tutto il logging di journald, visto che syslog fa solo una minima parte di quello che fà il primo.
Journald si occupa del logging di servizi, sistema, singoli demoni ecc.
Ecco perché in configurazioni di questo tipo avete certa roba loggata con syslogd e tutto il resto con journald.

L'obbiettivo a lungo termine è naturalmente deprecare definitivamente syslogd e fare affidamento solo su journald, come già avviene - per esempio - su ArchLinux.

Maskalamdug ha scritto:Il danno di solaris11 rispetto al 10 e che stanno passando tutto a SMF,dalle interfacce di rete(bene)
alla gestione dei servizi(male) quindi per chi viene dal mondo linux o solaris pre 11 vedere
la gestione di bind via SMF(con svccfg!) diciamo che è un piccolo problema.
Io sono abituato a modificare /etc/named.conf e dare rndc reload,non è più semplice
che editare degli xml con svccfg?
Certo che è più semplice.
Ma onestamente SMF è un caso a sé. È praticamente un giocattolo imbarazzante sviluppato 15 anni fa. Epoca in cui si pensava che usare XML su qualsiasi cosa fosse la panacea, perché """""auto-validante""""" e leggibile (LOL). Quindi era perfetto per i venditori di pentole.... ehm, per l'ENTERPRISE!!!
E difatti è il motivo per cui lo si usa moltissimo su Java e su .NET. Note piattaforme spinte e richieste dai venditori di pentole perché SCALANO!!1!!111!
Naturalmente, l'abuso di un linguaggio di markup, che non ha nulla a che vedere con le configurazioni, ha portato a mostri come SMF, che hanno bisogno di un parser XML e di uno strumento che prenda i valori parsati e li presenti nella classica struttura key=value. Anzi, key=data_type:value.
Questo ha portato all'ennesima soluzione over-engineered, che anziché mantenere semplice l'amministrazione ha creato un mostro inusabile, complesso come non mai, e talmente lento che fa quasi concorrenza ad IPS, il package manager di Solaris 11.
SMF è stato semplicemente un precursore. Una soluzione che ha avuto solo il beneficio di introdurre un concetto diverso e più avanzato di gestione dei servizi.
Tuttavia, è decisamente arrivato il momento di deprecarlo, sebbene sono convinto che la cosa non avverrà mai.
Ci fosse stata ancora SUN ed OpenSolaris in vita allora sì. Ma con Oracle ed il suo tenere Solaris in uno stato di eutanasia, una soluzione da distribuire a grosse banche o contesti IT che sono troppo legati a roba SUN per scappare via e alla quale succhiare il sangue il più possibile, direi che rimarrà lì fino alla fine.

systemd onestamente gioca in un'altra lega. Non lo si può nemmeno mettere a paragone.
Ha preso le idee buone dietro SMF (gestione a istanze, supervisione dei processi ecc.) e launchd (avvio dei servizi on-demand) e le ha implementate in maniera decisamente più sana, con una sintassi leggibile, facilmente parsabile, modificabile a mano e oramai riscoperta e sfruttata in diversi software (tipo mpv): INI.
INI è composta da una sola struttura: la sezione.
L'unica differenza tra la sintassi INI di systemd, il dialetto XDG (ovvero l'implementazione usata nei progetti Freedesktop), rispetto alla sintassi tradizionale (nata su Windows) è che al posto di usare il ";" come carattere indicante i commenti, usa "#" come su UNIX.

Codice: Seleziona tutto

# commento
[sezione1]
key1=value1
key2=value2
key3=value3

[sezione2]
key4=value4
key5=value5
key6=value6
Non esiste ereditarietà tra le sezioni (ovvero non esiste una sezione di una sezione), quindi si mantiene sempre una struttura elementare. Alcuni dialetti (non XDG) hanno implementato questa possibilità: [sezione_genitore.sezione_figlio]. Tuttavia è più un hack che una soluzione vera e propria.

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5284
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: certificazione LPIC

Messaggio da ZeroUno »

syslogd morirà quando l'occhio umano sarà in grado di leggere i file binari di journald senza tool diversi da more e grep.

Nel confronto tra linux e windows quello che è sempre risaltato sono i file di configurazione e log in formato testuale consultabili con vi contro il registro di configurazione consultabile con regedit e i log da apposita interfaccia.
I primi sono consultabili anche se l'host non fa il boot. I secondi beh, auguri se la macchina non sale.
Spero di non arrivare ad equipararli.

Gli INI di systemd non sono ancora arrivato a vederli, ma se è così è decisamente meglio degli xml che per quanto siano file di testo hanno una leggibilità relativa.

Launchd me lo devo vedere perché ho un applicazione che lo usa, anche se credo che usi una reimplementazione customizzata.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

hashbang
Packager
Packager
Messaggi: 1980
Iscritto il: ven 4 giu 2010, 10:27
Nome Cognome: Luca De Pandis
Distribuzione: macOS Catalina
Località: Lecce / Bergamo / Milano
Contatta:

Re: certificazione LPIC

Messaggio da hashbang »

ZeroUno ha scritto:syslogd morirà quando l'occhio umano sarà in grado di leggere i file binari di journald senza tool diversi da more e grep.

Nel confronto tra linux e windows quello che è sempre risaltato sono i file di configurazione e log in formato testuale consultabili con vi contro il registro di configurazione consultabile con regedit e i log da apposita interfaccia.
Guarda, sui log binari non sono convinto nemmeno io. Su systemd in sé ho cambiato idea da un po' e l'ho rivalutato parecchio, ma i log binari sono ancora una cosa che non mi piace.

Tuttavia, journald in sé non è necessariamente un male.
Ha dei concetti interessanti dietro, tipo quello di gestire tutti i log e di serializzarli allo stesso modo, eliminando così la necessità di creare parser esclusivi per ogni log.
Inoltre riduce anche la dipendenza dalle regex da parte dei sysadmin, in quanto permette direttamente con i suoi parametri di restringere l'output ad una determinata unit* e ad una determinata fascia oraria (--since=<data> --until=<data>). Permette inoltre di serializzarlo in formati differenti, tipo JSON.
I primi sono consultabili anche se l'host non fa il boot. I secondi beh, auguri se la macchina non sale.
Spero di non arrivare ad equipararli.
Oddio, non mi è mai capitata una situazione di questo tipo, quindi non posso risponderti.
Però, hai provato a lanciare dall'host "journalctl --root=/path/della/root ..."?
Stando al man di journalctl dice:
--root=ROOT

Takes a directory path as an argument. If specified, journalctl will operate on catalog file hierarchy underneath the specified directory instead of the root directory (e.g. --update-catalog will create ROOT/var/lib/systemd/catalog/database).
Onestamente, considerando che systemd è stato sponsorizzato come una soluzione soprattutto lato server, sarebbe ridicolo se non riuscisse a fare una cosa simile.

EDIT: Il parametro non è --root, ma -D, come dice il wiki di ArchLinux

Certo, farlo da macchine non Linux diventa un problema. Ma onestamente: quanti casi esistono di montaggio di file system Linux da host non Linux? :roll:
Windows non lo supporta di sicuro e gli altri UNIX idem, specie se si fa uso di file system moderni come Btrfs.

Di base l'uso del logging binario è semplicemente un cercare di aggirare la lentezza di grep e awk su grossi log.
Ma il problema è sempre lo stesso: si corrompono.
Certo, la corruzione di un log non lo rende necessariamente illeggibile, dato che è comunque consultabile eccetto per la riga che stava venendo scritta al momento del crash, tuttavia rimane il fatto che un log plain-text è più affidabile in quanto fa uso di un set di caratteri più ristretto.

Io, sinceramente, avrei implementato il tutto diversamente, con una chiave apposita all'interno di /etc/systemd/journald.conf, nella quale specificare il tipo di output: binario o plain-text, e specificando nella documentazione che si sarebbe potuto scegliere sulla base delle proprie necessità (affidabilità vs prestazioni) il tipo di formato da usare.

In questa maniera avremmo potuto evitare di mettere il redirect su syslogd, che è una soluzione ridicola, e avremmo potuto sfruttare direttamente tutte le capacità di journald anche su log plain-text.
Ma come ho già detto, è stata una mossa voluta. E questo è uno dei suoi punti negativi.
Launchd me lo devo vedere perché ho un applicazione che lo usa, anche se credo che usi una reimplementazione customizzata.
Launchd è il gestore dei servizi di Mac OS X ed è praticamente come SMF: manifest in XML. Più precisamente: formato PLIST, che è un XML ancora più verboso nel normale.


*unit: in systemd ogni cosa è una unit.
È molto simile al concetto di UNIX: tutto è un file, ma con la differenza che le unit sono file INI consultabili e sono soggetti al controllo di systemd, quindi possono essere soggetti al respawn in caso di caduta, avere dei limiti imposti dai cgroup ecc.
Una unit può essere un servizio, un timer (un'operazione pianificata. Il nostro cron, per farla breve), un mount-point, un target, una swap, un socket ecc.

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5284
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: certificazione LPIC

Messaggio da ZeroUno »

hashbang ha scritto:
I primi sono consultabili anche se l'host non fa il boot.
Oddio, non mi è mai capitata una situazione di questo tipo, quindi non posso risponderti.
Fortunatamente non capita spesso, ma è un caso in cui l'accesso ai log è fondamentale che sia più immediato possibile.
Però, hai provato a lanciare dall'host "journalctl --root=/path/della/root ..."?
Ho lanciato journalctl una sola volta in vita mia, due gg fa, quindi no, non ho provato. Però avere il comando journalctl a portata di mano quando fai boot da cd (qualsiasi, sia della distro, sia di rescue sia di un'altra distro) non è scontato (il more c'è sempre).
Certo, farlo da macchine non Linux diventa un problema. Ma onestamente: quanti casi esistono di montaggio di file system Linux da host non Linux?
mi verrebbero in mente un mare di esempi ma te ne faccio uno solo.
Noi storicizziamo i log (una volta compressi) su una share nfs comune a tutti per tenerli almeno un anno, per averve immediato accesso a tutti i log in un solo luogo e per generare statistiche e altre varie cose da qualsiasi host, linux e solaris (e rari windows).
Pensa ad un
zgrep Error messages_nomemacchina[1234].log.gz

Mi viene già in mente lo scenario (sicurissimo) che a fine giornata uno script in cron esporta i log in formato testo con journalctl, li mette sulla share nfs e si continua ad accedere nel vecchio sistema, perdendo qualsiasi vantaggio abbia aggiunto journald.

Vedetemi come san tommaso.. finchè Pat non lo mette in slackware non credo ;)

Purtroppo avrò a che farci prima. Già abbiamo un host di test con redhat 7 (e tutto ciò che è connesso).
Nonostante per i nuovi progetti spingerò a rimanere finchè possibile con redhat 6 (e già è tanto, perchè server messi in piedi un anno fa li ho fatti con redhat 5 che preferisco di gran lunga), non è pensabile di rimanere con questa in eterno. Solo per dire, ancora ha un kernel 2.6, che seppure lts e con backport di patch da parte di redhat, resta pur sempre con uno stack software (cioè non solo kernel) vecchio.
Prima di anche solo pensare di vederlo su slackware (systemd con o senza journald; ubuntu 14 ha systemd ma non journald) devo ma proprio essere *convinto* che sia la cosa migliore e che non se ne *deve* fare a meno!!!

Launchd è il gestore dei servizi di Mac OS X ed è praticamente come SMF
come dicevo è una versione customizzata dello specifico software che - secondo me - ne ha preso il nome e basta. Ma per saperlo devo attendere metà febbraio (ora non ho accesso alle macchine)

*unit: in systemd ogni cosa è una unit. [...]
grazie della spiegazione
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
brg
Linux 2.x
Linux 2.x
Messaggi: 470
Iscritto il: sab 12 mar 2011, 14:20
Slackware: 14.2
Kernel: 4.4.172
Desktop: KDE4
Località: Montecatini
Contatta:

Re: certificazione LPIC

Messaggio da brg »

ZeroUno ha scritto: a fine giornata uno script in cron esporta i log
Intendevi dire un systemd.timer, vero? :D

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5284
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: certificazione LPIC

Messaggio da ZeroUno »

Pure!!!
Piuttosto me lo simulo con uno script
while true ;do.... done

Scommetto che cpanel e questi programmi qua ci vanno a braccetto (configurare un sistema senza parsare file deve essere una manna)
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5284
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: certificazione LPIC

Messaggio da ZeroUno »

fsckd ?

/run/resolvconf/resolv.conf ?

dico, a parte il kernel, c'è rimasto qualcosa di gnu/linux ?
tra poco ci metteranno pure vmlinuzd e allora dovremo chiamare le distribuzioni gnu/systemd !!
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Rispondi