Pagina 1 di 1

Slackware per un server PRO e CONTRO

Inviato: mer 31 ago 2011, 1:45
da Plaoo
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.

Re: Slackware per un server PRO e CONTRO

Inviato: mer 31 ago 2011, 9:18
da notsafe
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)

Re: Slackware per un server PRO e CONTRO

Inviato: mer 31 ago 2011, 9:24
da ilmich
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.

Re: Slackware per un server PRO e CONTRO

Inviato: mer 31 ago 2011, 9:47
da krisis
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 :
  • 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.
Se devi usare hardware con certificazioni di compatibilità verso linux e vuoi usufruire del supporto tecnico devi usare una distribuzione certificata, l'esempio migliore che possa fare è la Dell : se hai problemi di compatibilità o funzionalità del sistema operativo riconducibili all'hardware ed usi una distribuzione non certificata il supporto può tranquillamente chiuderti la telefonata in faccia (a meno di accordi preliminari ben precisi)
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".

Re: Slackware per un server PRO e CONTRO

Inviato: mer 31 ago 2011, 11:27
da fgcl2k
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)
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.

Re: Slackware per un server PRO e CONTRO

Inviato: mer 31 ago 2011, 18:29
da Meskalamdug
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 :D
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...

Re: Slackware per un server PRO e CONTRO

Inviato: mer 31 ago 2011, 18:48
da ZeroUno
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)