YAST e tool di configurazione per gentoo

[Nemesix2001]

@SilverXXX ftp://ftp.gwdg.de/pub/linux/suse/ftp.suse.com/suse/i386/9.2/suse/src/

@fat_penguin non credo sia impossibile da fare....il problema è che i tool come quelli sono stati portati avanti con l'incombenza di release ogni 6 mesi e si è lasciata da parte la ricerca di pulizia che invece ha strenuamente difeso una distro come la slack...che però manca di develepor sufficienti per avere molte cose figuriamoci se in cima alle priorità c'è un tool grafico per la gestione del sistema... però ciò non toglie che partendo con l'idea cardine di mantenere il sistema ordinato e leggibile con un editor di testo si può costruire qualcosa... non dico io però la comunità GNU/Linux può senza dubbio ne sono convinto...

Per randomaze o i mod in genere....il titolo va bene così?

[akiross]

Si si, tool di configurazione sono fattibilissimi... alla fine e' solo modifica del testo (sapendo usare bene lo shell scripting si puo' fare tranquillamente questa operazione con qualche tool e regexp). Aggiungere la grafica non e' niente di piu' che limitare le possibilita' dell'utente o mettere un valore diverso da quello di default.

Un problema e' adeguarsi allo standard del programma.

Mi spiego: il tentativo migliore che possiamo fare e' riprodurre in automatico lo stesso procedimento secondo il quale noi andiamo ad editare il file a mano.
L'edit del file a mano equivale a:
1. Decisione dei valori da inserire
2. Localizzazione dei punti di inserimento/modifica
3. Inserimento/Modifica

In altre parole:
1. L'utente sceglie lo script/clicca il pulsante che indica cosa vuole fare, e inserisce i dati richiesti alla modifica (esempio: voglio aggiungere il modulo ABC.1.so al file di config di apache)
2. Secondo un file di regole, definito da noi, il programma sa in che posizione del file deve guardare per fare l'inserimento: in apache e' necessario localizzare il tag (sparo a caso) <modules></modules> ed inserire una riga all'interno di esso
3. Inserimento dello stesso, o modifica del dato. Se ad esempio vogliamo passare dal modulo ABC.1.so al 2.so, dovremo avvisare il programma che non deve inserire una riga ma deve modificare una esistente

Facendo queste 3 operazioni in serie e' possibile la modifica del file.

Ora stavo pensando all'effettivo sviluppo: innanzi tutto sarebbe bene creare un engine di base (o usare un frontend ai comandi shell) per modificare i file. Questo significa che noi istruiamo l'engine dicendo:
FIND "<modules>"; ADD LINE "ApacheModule ABC.1.so"
oppure
FIND "ApacheModule ABC.1.so"; MODIFY PATTERN "ABC.1.so" TO "ABC.2.so"
Queste due linee sono scritte in un ipotetico codice che ci permette di manipolare l'engine. Ovviamente si puo' fare anche tramite C, Perl o Python, non importa come.

Poi fatto questo (e quindi facendo delle modifiche a mano mediante un engine) noi dovremmo costruire delle regole per ogni file di config (ovvero un file che ci dice:
Per aggiungere un modulo ad apache si deve fare:
<istruzione di aggiunta in quel linguaggio>
Per modificare un modulo si fa
<istruzione di modifica in quel linguaggio>
Per aggiungere un'estensione mime si fa
<istruzione per aggiungere un MIME>
eccetera.
Fatto questo file di config noi possiamo fare delle modifiche automatiche mediante il nostro engine. L'ultimo passo e' costruire una GUI che prende i moduli, ne ricava le informazioni, crea menu' con le possibili modifiche e li spara all'utente via grafica.

Senza contare che in questo modo possiamo usare 1 engine per molti moduli diversi adatti ad una specifica distro/applicazione. E creare l'interfaccia utente in modi diversi ma con la stessa base (GTK, QT, ncurses, command line...)

Se YAST funzionasse cosi' sarebbe una cosa favolosa.... basterebbe solo studiarne il funzionamento e creare i moduli appositi.

Il discorso in se non e' complesso da fare: basta studiare bene la situazione e capire i possibili interventi che vogliamo fare sui file. Creare un linguaggio/sintassi per manipolare i file (o usare un tool gia pronto... sed o awk magari) e' un ulteriore livello di astrazione che si tramuta in portabilita' e scalabilita'.
Il problema e' che e' relativamente lungo da implementare

Ciauz
_________________
Libera scienza in libero stato.
Horizon of Events

[akiross]

[SilverXXX]

@ nemeisx: grazie, cmq adesso sto scaricando suse 9.2 dvd, per vedere come sono messi con la nuova versione

@akiross: effettivamente ci sarebbe un bel pò di lavoro da fare, ma non credo che sarebbe lungo quanto dici te. Però, imho, usando il tuo sistema (che sarebbe l'ideale per non stravolgere la sistemazione corrente dei file e la loro sintassi interna) ci sarebbe un notevole "spreco" forze, perchè qualcuno si deve occupare dei file per i vari programmi e/o file di sistema, e poi le varie distro dovrebbero comunque ripassarli, se non altro per controllare le posizioni dei file. Però è fattibile
_________________
about:mozilla

[unz]

@fat
non capisco questo tuo incaponimento ... qui si parla di una specie di pannello di controllo ... una gui che ti possa far settare le opzioni con i click [e ai più potrebbe anche far conoscere opzioni mai viste in quanto l'help dei comandi viene usato al massimo dal 20% degli utenti] ... non vedo il problema "morale" che possa esserci dietro ... come ha detto random linee e linee fa ... se lo vuoi lo emergi, se no nisba ... non penso proprio che una gui porterà alla distruzione di una filosofia o un SO ...

ps starai navigando il forum con lynx naturalmente ...
_________________
Ma che c'hai là? Sulla spalla!!!! http://lascimmia.it/

[akiross]

Si ma conta che se non c'e' nessuno che stia li a scegliere il miglior modo per tenere ordinato un file di config, il file di config non diverra' *mai* ordinato.

Comunque un grosso problema e' anche la centralizzazione: usare un tool che fa esattamente quello che facciamo noi non e' come avere un tool che tiene un suo proprio registro per le modifiche. Quindi mentre nel 2o caso modifiche a mano sono poco piacevoli, nel primo non dovrebbe esserci nessun problema nello switch mano/automatico.

Ciauz
_________________
Libera scienza in libero stato.
Horizon of Events

[randomaze]

[SilverXXX]

Il fatto che nessuno abbia fatto niente fino adesso, non è di sicuro un buon motivo per desistere. Per esempo adesso finalmente x.org a imboccato la via giusta, quando le nuove estensioni saranno stabili avremo un sistema a finestre più reattivo. Anche se di tempo ce ne è voluto, qualcosa si vede di buono ora. E cmq, non si parla di modifiche fatte per nostro divertimento ma teoricamente per il bene di tutti.
_________________
about:mozilla

[akiross]

Onestamente ho letto la doc sul sito di elektra e lo trovo un ottimo progetto. Non dico che dovrebbe diventare lo standard, ma offre sicuramente tanti vantaggi (con anche svantaggi suppongo).

Secondo me vale la pena iniziare ad usarlo e chiedere che venga usato nelle applicazioni. Non dico che init debba usare elektra, ma se fosse uno standard ci sarebbero meno problemi per molte cose.

Il problema e' (come ha detto randomaze) che scrivere una patch per ogni sw e' mostruoso. Io avrei usato un termine piu' soft, perche' alla fine non si parla di riscrivere un software: se un programma e' progettato bene la modifica della lettura/scrittura delle configurazioni dovrebbe essere abbastanza staccato dal resto del motore, e quindi non sarebbe neanche cosi' problematico.

L'unico ostacolo che vedo davvero e' il tempo che si impiegherebbe nel passare ad un sistema simile: a meno che elektra non si diffonda come standard e mezzo ampiamente piu' vantaggioso, non credo che tutti i developer del free software corrano a fare patch per questo sistema.

In ogni caso mi sembra giusto provare (cosa che sto per fare) elektra, farlo conoscere agli altri e se - per motivi seri - si rivelasse comunque svantaggioso allora le cose rimarranno come stanno.

Comunque io ho sempre desiderato un layer di questo tipo per le configurazioni... una delle cose che ho sempre odiato e' dover scrivere engine per leggere file ini o di configurazione.

Ciauz
_________________
Libera scienza in libero stato.
Horizon of Events

[randomaze]

[fedeliallalinea]

[fat_penguin]

[fat_penguin]

[akiross]

fat_penguin ti sei accorto che questi tool sono sviluppati da gentooisti per gentooisti? Non stiamo parlando di usare un sistema a GUI tipo YAST su gentoo. Stiamo parlando di usare un sistema GUI tipo YAST che non faccia casino.

Questo significa che se l'idea va in porto tu non dovresti accorgerti quando un file l'hai editato tu (o un altro essere umano) o quando l'ha fatto il tool gui (che potrebbe anche essere yast)

Ciauz
_________________
Libera scienza in libero stato.
Horizon of Events

[akiross]

Ehm, attenzione a parlare dei Registri, Elektra e cose simili perche' sono cose tabu'. Occhio che magari qualche moderatore un po' troppo di parte vi toglie la liberta' di espressione... Non preoccupatevi italiani, parlavo di un moderatore globale.

In ogni caso, sembra che questo genere di cose non abbia avuto molto successo https://forums.gentoo.org/viewtopic.php?p=1955824#1955824
e https://forums.gentoo.org/viewtopic.php?t=209633

Pero' consentitemi una libera espressione: leggendo il secondo thread mi viene da pensare che troppi utenti linux siano bacati. E' cosi' evidente che il metodo attualmente usato - anche se funziona - non e' il massimo che non so neanche come rispondere. [edit: onestamente credo che difendere linux solo perche' attualmente ci si smanetta su e si ha paura che in futuro la cosa possa cambiare mi sembra proprio l'espressione di non aver capito come funziona linux]

Detto questo, anche se un registro non va bene (lasciando stare che nessuno capisce mai un c***o di quello che legge, difatti li parlavano di database (???) registri binari (???) e altre vaccate che non si sono mai elencate nell'introduzione a elektra, senza contare che troppi non si sono mai resi conto che il registro di windows fa schifo per come e' fatto, non perche' sia un registro) mi sembra evidente che sarebbe una bella cosa adottare dei file di configurazione standard. Se per l'idiozia della gente non si puo' usare una layer in piu' che si occupa di questa cosa, a questo punto che si fa? Tutti a creare file di config XML con expat? Si ok, a me andrebbe bene anche cosi' (l'obbiettivo di omogeneizzare si raggiunge comunque quasi del tutto), ma se ci si puo' appoggiare ad un -buon- livello di astrazione in piu' non vedo perche' non farlo. Non credo che le performance siano cosi' tagliagambe come si dice.

Il problema e' che se non si trova un modo per rendere i file di config omogenei a questo punto si deve fare come dicevamo prima un modulo per ogni file di configurazione possibile, il che e' un po' da suicidio.
_________________
Libera scienza in libero stato.
Horizon of Events

[randomaze]

[akiross]

Si si, ok. Ma se apro un nuovo thread, me lo sposta nei duplicati (e non posso piu' rispondere), e l'originale e' chiuso mi spieghi dove parlo dell'argomento?
Ne apro un altro che finira' nei duplicati?

A me sembra una censura bella e buona.
_________________
Libera scienza in libero stato.
Horizon of Events

[maxxl]

Scusate se arrivo solo adesso, come si dice allo sparo finale, ma proprio questa sera mi è venuto in mente di vedere se c'era qualcuno che avesse pensato all'integrazione di yast con altre distribuzioni Linux (dopo il suo rilascio in OS) e mi sono imbattuto in questo thread.

Leggendo tutto quello di cui si è discusso mi è venuto in mente quanto segue. Premetto che i primi firewall su Linux lì ho fatti manualmente e adesso uso FwBuilder e vi assicuro che mi ci trovo benissimo. Questo tool non fa altro che lavorare su un file in XML che poi viene compilato in uno shell script che contiene dei comandi iptables.

Quindi perchè non modificare yast in modo da gestire solo file xml che poi vengono trasformati in appossiti file di configurazione per i vari server. Questo significa che bisognerebbe creare 2 file di configurazione, uno che definisce l'interfaccia per yast as esempio un apache.yast.conf ed un parser che dall'xml che yast dovrebbe produrre tiri fuori il classico httpd.conf.

Inoltre rifacendosi all'idea degli editor WYSIWYG chi modifica il file potrebbe editare il sorgente (parlo dell'XML) e aggiungere il proprio codice custom.

Naturalmente le distribuzioni non dovrebbero più fornire file di configurazione preconfigurati, ma bensì file XML preconfigurati che in fase di installazione vengono compilati nei relativi file di configurazione. In questo modo in futuro i programmi potrebbero spostarsi proprio sul file XML evitanto il parsing transitori XML --> conf standard (come adesso iniziano a fare i vari programmi Winzoz con i file di manifest).

Perdonate le eventuali cazzate sparate, ma essendo arrivato allo sparo non potevo fare altro.

[mouser]

Mi reinserisco in questo 3d per esprimere un paio di miei pensieri.
Per prima cosa, rispondendo a fat_penguin anche se mi sembra che la tua idea sia chiara e assolutamente non sbagliata, quello che distinguerebbe un'eventuale YAST per gentoo da quello per Suse, dal Pannello di Controllo di Windows, sta nella possibilita' di fare

[SilverXXX]

mouser, sono d'accordo sul fatto di poter mettere yast (o qualunque altro pannello o utility) e poterlo togliere, poter fare modifiche a mano o tramite click, ma non si steve parlando "semplicemente" di portare yast anche su gentoo, ma di fare qualcosa per lo stato attuale delle configurazioni linux: oltre ad avere locazioni diverse da distro a distro, ogni file ha una propria sintassi, completamente diverse per ognuno. Ci vorrebbe qualcosa di unificato per poter fare qualcosa come dei pannelli di controllo standard.
_________________
about:mozilla

[mouser]

Bhe' credo che il tentativo di standardizzare le varie distro sia gia' stato fatto in passato, con scarsi risultati, e che il raggiungere uno standard per le distribuzioni si debba compiere a piccoli passi.
Credo che, anche se si dovesse riuscire a definire uno standard funzionale e logico, non si potra' mai un bel giorno prendere utenti, amministratori di sistema, sviluppatori di distribuzioni, di software e di driver e dirgli rispettivamente "Bene utente, d'ora in poi se vuoi modificare i settaggi per la scheda di rete editi questo file; e tu, sistemista, devi riconfigurare i tuoi ambienti chrootati, per tutti le distro che hai installate, andando a vietare l'accesso a quella conf; sviluppatore di software ed di driver: riscrivimi il tuo per aderire allo standard"
Forse non mi sono spiegato bene: sarebbe veramente l'ideale se qualsiasi distro prendo, posso modificare i runlevel nella stessa dir, con la stessa sintassi, ma non credo che questo possa essere fatto dall'oggi al domani.
Credo invece che si possa iniziare a sensibilizzare LE comunita' allo sviluppo ed all'utilizzo di tool che, per quanto siano diversi implementativamente parlando, offrano la stessa funzione su diverse distro. Poi, quando tutti sono felici, si inizia a convincere ad uniformare il sistema.
Insomma, prima per quanto sia diversa la distro, gli abitui ad avere gli stessi tool per fare le stesse cose.... poi li convinci ad avere la stessa struttura di fs.

Tutto questo IMHO
Ciriciao
mouser

[SilverXXX]

Che ci voglia molto tempo, sono pienamente d'accordo. E purtroppo è proprio questo il problema; l'approccio che tu suggerisci (che è corretto, per essere), imporrebbe un notevole utilizzo di risorse 2 volte: quando si crea il tool standard che ogni distribuzione dovrebbe in parte modificare per farlo andare (a volte basta cambiare il path di un file, ma non è sempre detto), e quando si crea opi lo standard diciamo definitivo. Purttoppo però questo, la dispersione delle forze, è uno dei limiti dell'opensource, ed essnedo intrinseco nel modo di essere di linux, non si potrà mai raggiungere certi risultati..
_________________
about:mozilla