Slackware per un server PRO e CONTRO
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.
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.
- Plaoo
- Linux 3.x
- Messaggi: 809
- Iscritto il: gio 10 apr 2008, 17:40
- Slackware: 14 64
- Kernel: 3.2.9
- Desktop: KDE
- Località: Ittiri (SS)
Slackware per un server PRO e CONTRO
Apro questa discussione perchè sull altra stavamo andando OT (viewtopic.php?f=2&t=34691).
Usare slackware per un server che ne pensate?
Vantaggi e svantaggi.
Usare slackware per un server che ne pensate?
Vantaggi e svantaggi.
Il canale ufficiale di slacky.eu si trova sui server irc.syrolnet.org canale #slackware
Re: Slackware per un server PRO e CONTRO
rispondo qui alla richiesta di esempio nella precedente discussione.
Caso che che mi è capitato (e che prescinde da Slackware): qualche anno fa abbiamo avuto alcuni problemi con named che "improvvisamente" si uccidevano.
Dopo un pò di analisi,abbiamo compreso il problema: da una certa versione in poi (ora non mi ricordo esattamente quale,si parla di almeno 3 anni fa) il comportamento di default di named in presenza di una doppia zona è quello di fermare completamente il processo,mentre prima semplicemente veniva eseguito un secondo load (e quest'ultimo "vinceva" su quello precedente): questo cambiamento,oltre a darci ovvi problemi di disservizio,ci ha obbligato a modificare gli script di distribuzione delle zone (implementando un algoritmo di controllo sulla eventuale presenza di stesse zone in due include diversi)
Caso che che mi è capitato (e che prescinde da Slackware): qualche anno fa abbiamo avuto alcuni problemi con named che "improvvisamente" si uccidevano.
Dopo un pò di analisi,abbiamo compreso il problema: da una certa versione in poi (ora non mi ricordo esattamente quale,si parla di almeno 3 anni fa) il comportamento di default di named in presenza di una doppia zona è quello di fermare completamente il processo,mentre prima semplicemente veniva eseguito un secondo load (e quest'ultimo "vinceva" su quello precedente): questo cambiamento,oltre a darci ovvi problemi di disservizio,ci ha obbligato a modificare gli script di distribuzione delle zone (implementando un algoritmo di controllo sulla eventuale presenza di stesse zone in due include diversi)
-
- Master
- Messaggi: 1645
- Iscritto il: lun 16 lug 2007, 17:39
- Slackware: 15.0 64bit
- Kernel: 5.15.27
- Desktop: kde
- Località: Roma
Re: Slackware per un server PRO e CONTRO
Secondo me Slackware non avendo ufficialmente la compatibilità con prodotti proprietari (Oracle, Ibm etc etc etc) non è adatta in tante situazioni enterprise.
In più non ha nessun tipo di certificazione(correggetemi se sbaglio), in pratica a livello burocratico non verrà mai adottata in contesti di alto livello.
Però a parte questo, fino a quando si parla di server basati su software opensource(quindi compilabile in un apposito ambiente di build) non trovo grossi svantaggi.
In più non ha nessun tipo di certificazione(correggetemi se sbaglio), in pratica a livello burocratico non verrà mai adottata in contesti di alto livello.
Però a parte questo, fino a quando si parla di server basati su software opensource(quindi compilabile in un apposito ambiente di build) non trovo grossi svantaggi.
- krisis
- Linux 4.x
- Messaggi: 1120
- Iscritto il: mar 25 gen 2005, 0:00
- Distribuzione: debian
- Località: Roma
Re: Slackware per un server PRO e CONTRO
In realtà se parliamo di server va bene quasi qualsiasi distribuzione.
Tutto dipende dal gruppo di sistemisti che gestisce il ced.
Avere o meno un packet manager che mi risolva le dipendenze automaticamente non è un prerequisito se il server dovrà restare immutato per i prossimi tre anni (tranne gli aggiornamenti di sicurezza).
La mancanza di pam in slackware invece è molto più rognosa se si ha intenzione di usare metodi di autenticazione più evoluti come ldap+kerberos,ma anche in questo caso se il team di sistemisti ha deciso di usare slackware sapendone le limitazioni sapranno anche come risolvere il problema.
Le uniche distribuzioni da installare su di un server che vanno evitate come la peste sono le rolling , le current e qualsiasi altra tipologia che faccia aggiornamenti massivi quasi giornalieri che non preveda un ramo stable con un lungo periodo di supporto.
In alcuni ambiti particolari invece la scelta della distribuzione è obbligatoria :
Ma anche in questi casi se il team di sistemisti ha deciso diversamente sapendo a cosa andava incontro sa anche come risolversi il problema.
Non c'è esattamente un meglio o un peggio fra le distribuzioni , c'è invece "sistemista consapevole e sistemista scalzacani".
Tutto dipende dal gruppo di sistemisti che gestisce il ced.
Avere o meno un packet manager che mi risolva le dipendenze automaticamente non è un prerequisito se il server dovrà restare immutato per i prossimi tre anni (tranne gli aggiornamenti di sicurezza).
La mancanza di pam in slackware invece è molto più rognosa se si ha intenzione di usare metodi di autenticazione più evoluti come ldap+kerberos,ma anche in questo caso se il team di sistemisti ha deciso di usare slackware sapendone le limitazioni sapranno anche come risolvere il problema.
Le uniche distribuzioni da installare su di un server che vanno evitate come la peste sono le rolling , le current e qualsiasi altra tipologia che faccia aggiornamenti massivi quasi giornalieri che non preveda un ramo stable con un lungo periodo di supporto.
In alcuni ambiti particolari invece la scelta della distribuzione è obbligatoria :
- Se devi usare il database oracle su di un installazione linux devi usare centos , redhat , unbreakable linux o suse.
Se devi usare weblogic o websphere su di un installazione linux devi usare centos , redhat , unbreakable linux o suse.
Se devi usare sap o siebel su di un installazione linux devi usare redhat o suse.
Ma anche in questi casi se il team di sistemisti ha deciso diversamente sapendo a cosa andava incontro sa anche come risolversi il problema.
Non c'è esattamente un meglio o un peggio fra le distribuzioni , c'è invece "sistemista consapevole e sistemista scalzacani".
- fgcl2k
- Linux 1.x
- Messaggi: 137
- Iscritto il: gio 29 ott 2009, 10:14
- Nome Cognome: Federico
- Slackware: 14.1 (64bit)
- Kernel: 3.10.17
- Desktop: KDE 4.13.3
Re: Slackware per un server PRO e CONTRO
Ok, ho capito cosa intendi dire. Anche installando una versione stabile di Slackware potevo avere un aggiornamento di sicurezza che mi faceva passare alla nuova versione di bind che presentava un comportamento diverso. Una distribuzione come Debian o Centos (ma anche Ubuntu, credo) che effettua i backport delle fix di sicurezza sulle vecchie versioni non avrebbe avuto questo problema.notsafe ha scritto:rispondo qui alla richiesta di esempio nella precedente discussione.
Caso che che mi è capitato (e che prescinde da Slackware): qualche anno fa abbiamo avuto alcuni problemi con named che "improvvisamente" si uccidevano.
Dopo un pò di analisi,abbiamo compreso il problema: da una certa versione in poi (ora non mi ricordo esattamente quale,si parla di almeno 3 anni fa) il comportamento di default di named in presenza di una doppia zona è quello di fermare completamente il processo,mentre prima semplicemente veniva eseguito un secondo load (e quest'ultimo "vinceva" su quello precedente): questo cambiamento,oltre a darci ovvi problemi di disservizio,ci ha obbligato a modificare gli script di distribuzione delle zone (implementando un algoritmo di controllo sulla eventuale presenza di stesse zone in due include diversi)
-
- Iper Master
- Messaggi: 3961
- Iscritto il: ven 14 mag 2004, 0:00
Re: Slackware per un server PRO e CONTRO
Slackware ha sui server vantaggi e svantaggi
il primo vantaggio è che è semplice,pulita,senza fronzoli
con tutto quello che ne consegue.
Lo svantaggio è che manca un repository serio per
installare pacchetti,quindi facendo un pdc con ldap
e i relativi tools...vi dovete compilare tutto a mano
con quello che ne segue
Poi ovviamente tutto dipende dal contesto..io come
server di posta slackware la vedrei benissimo,o anche
come server dns,o http,o kdc kerberos,anzi la vedrei
meglio di tante altre distro.
Mentre la vedrei dura per fare un sso...
il primo vantaggio è che è semplice,pulita,senza fronzoli
con tutto quello che ne consegue.
Lo svantaggio è che manca un repository serio per
installare pacchetti,quindi facendo un pdc con ldap
e i relativi tools...vi dovete compilare tutto a mano
con quello che ne segue
Poi ovviamente tutto dipende dal contesto..io come
server di posta slackware la vedrei benissimo,o anche
come server dns,o http,o kdc kerberos,anzi la vedrei
meglio di tante altre distro.
Mentre la vedrei dura per fare un sso...
- ZeroUno
- Staff
- Messaggi: 5441
- 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: Slackware per un server PRO e CONTRO
Slackware non verrà mai usata in grandi ambienti perchè... non si paga.
Che paradosso, vero?
Però se non funziona qualcosa la ditta può dire al fornitore: "io ti sto pagando! risolvilo o sono guai!"
Se uso slackware e non so risolvergli il problema il massimo che può succedere è che la ditta ti licenzi, ma il problema gli rimane, e spesso gli costa molto di più tenersi il problema che pagare il supporto redhat o sun o ibm o addirittura microsoft, a seconda dei casi.
E se il fornitore non riesce a risolvere i guai la ditta va per vie legali (e riesce a rifarsi un bel po' di quello che ha perso a causa del guaio)
Ecco come funziona il mondo... anche nell'opensource (eh si, perchè redhat te lo puoi installare gratis ed usare liberamente. quello che paghi è il supporto e le patch)
Che paradosso, vero?
Però se non funziona qualcosa la ditta può dire al fornitore: "io ti sto pagando! risolvilo o sono guai!"
Se uso slackware e non so risolvergli il problema il massimo che può succedere è che la ditta ti licenzi, ma il problema gli rimane, e spesso gli costa molto di più tenersi il problema che pagare il supporto redhat o sun o ibm o addirittura microsoft, a seconda dei casi.
E se il fornitore non riesce a risolvere i guai la ditta va per vie legali (e riesce a rifarsi un bel po' di quello che ha perso a causa del guaio)
Ecco come funziona il mondo... anche nell'opensource (eh si, perchè redhat te lo puoi installare gratis ed usare liberamente. quello che paghi è il supporto e le patch)
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111