madko a écrit 395 commentaires

pkgorder est mal codé concernant la verification de certains groupes, le nom des groupes est carrement en dur dans pkgorder. Donc le plus simple est de recreer ces groupes (t'as la liste qq part dans pkgorder) mais vide.

la base de données remplace juste les fichiers à plat qu'utilise de base un MTA. L'avantage est multiple, on peut facilement construire des pages d'administration/gestion accessibles par web (en php par ex), et comme le MTA interroge la base avec du sql, il est plus trop necessaire de relancer le MTA a chaque modif (c'est moins le cas avec les fichiers a plat, qui sont en general uniquement chargés au lancement du mta).

La gestion des utilisateurs passe plutot par le concept d'utilisateur virtuel, et de plus le mot de passe peut tout à fait (et c'est meme recommandé) etre crypté dans la base SQL. Donc pas tellement de soucis niveau sécurité.

merci pour l'info, j'ai decroché slackware depuis que Gnome a été viré mais j'essaye de suivre quand meme

jtesterais slackpkg ça m'a l'air bien

il y a toujours swaret pour mettre à jour sa slackware?

et bien un petit yum groupinfo Base et yum groupinfo Core t'indiquera la liste des packages qui sont presque nécessaires et obligatoire pour avoir un système fonctionnel

Sinon regarde un comps.xml de fedora, il est présent sur les cd dans Fedora/base
Tu y retrouvera les groupes Base et Core (et les autres)

Je suis parti sur ça, en nettoyant un peu. Et après il faut pas s'inquiéter, comme j'initialise une base rpm vide, yum calculera toutes les dépendances nécessaires, donc même si t'oublie un rpm important yum risque de se débrouiller. Le but dans le comps.xml n'est pas de lister TOUS les packages.

j'oubliais le fedora-logos a customiser. Il contient les logos/images qu'on voit un peu partout, dès l'install graphique jusqu'au bouton du menu gnome ;)

Jsuis en train justement d'ecrire une ptite doc la dessus je la posterais des que possible

En gros je passe par 7 etapes:

Au préalable il faut avoir une liste de packages qu'on veut installer afin de creer le comps.xml contenant les groupes et packages dont tu a besoin. Il faut creer certains groupes qui sont obligatoires (pkgorder de RH est pourri certains noms de groupe sont ecrit en dur dans le code) mais bon ils peuvent etre vide. Pour ça je passe par un fichier a plat, et ensuite un ptit script qui mouline ça en xml. Une fois le comps.xml bien définit on peut commencer

1) Recuperer les packages et leurs dépendances, ici je passe par yum + un ptit plugin bidon fait maison pour qu'il se contente juste de télécharger tous les packages. Ya surement d'autres methodes

2) Creer et placer les RPMS dans un repertoire ayant l'arborescence de notre futur CD (cad les RPMS dans ./Fedora/RPMS par ex, le comps.xml dans ./Fedora/base)

3) Etape qui n'est à faire que de temps en temps, preparer la construction d'anaconda. Donc ici il faut avoir le contenu de tous les CD fedora sous la main, mais à ne pas melanger avec le contenu de notre futur CD

4) Etape à faire au moins une fois. On peut enfin construire Anaconda. Avant on peut virer les fichiers packages de kernel en rpm pour mettre les plus récent (issus des updates fedora). Comme ça quand on va lancer le buildinstall c'est le nouveau noyau qui sera utilisé. Il faut aussi avoir installé certains packages (comme netpbm ;) )
C'est avec le buildinstall qu'on peu renommer notre distrib (avec les option --release, product etc)
Placer les fichiers générés (isolinux et les stage2.img) dans notre futur arbo de cd

5) On genere le ks.cfg (ou les ks.cfg) pour automatiser notre install. On les copie ensuite dans le rep d'isolinux

6) Etape optionnel, modifier les fichier msg de isolinux (histoire d'indiquer les different ks.cfg pour les differents profils)

7) Creation de l'iso, un bon vieux mkisofs


Voila en gros, mais si t'a des questions sur certains points n'hesite pas. Pour la construction de la RHEL AS4 c'etait un peu plus artisanal et on utilisait urpmi pour le calcul des dependances etc

là ce que j'ai justement c'est une distrib fedora, où j'indique juste un profil au boot du cd et tout le reste de l'install se fait de maniere automatique

J'ai bien une dizaine de profils (serveur web, dns, squid, nagios etc) le tout tenant sur 1 seul CD.

Donc en mettant juste le strict minimum + gnome ça doit largement etre jouable

bon ça y est ça marche enfin

j'ai perdu quelques jours juste parcequ'il me manquait netpbm pour le splashscreen du bootloader. Jme disais c'est pas grave, j'en veux pas, ba finalement sans ça le fameux buildinstall termine mal la creation du stage2.img ...

donc en gros pour customiser 1 ou 2 fichiers du cd pour l'install, il m'a fallu pas mal d'heures de recherche, la copie integrale de tous les CD fedora (c'est surtout cette partie là où j'y croyais pas), beaucoup d'iso, et pas mal de qemu

bravo

merci pour vos conseils, liens (et encouragements) ça m'a bien aidé :)

nan le --comp est obligatoire, enfin du moins sur mon buildinstall

par contre ça a pas l'air de servir a grand chose

bon sinon jai resolu toute les erreurs, en fait ils faut copier tout le contenu de tous les cds fedora pour reconstruire les images de l'installeur (ouai c'est du lourd). Du coup j'ai un nouveau soucis.

Le probleme est que maintenant Anaconda quand je boot sur le CD custom il me le detecte pas, ou le concidere pas comme son cd d'install.

Alors j'ai remarqué 2 choses:

1) il y a un fichier .buildstamp dans le stage2.img, mais dans celui-ci je vois toujours comme nom de produit "Fedora Core 5" et pas le ptit nom que j'ai indiqué à buildinstall (c'est bien la peine)

2) Dans les logs Anaconda sur le CD, quand l'installeur me dit que le CD est pas le bon, j'ai ça:

Unable to load NLS charset utf8
ISO 9660 Extensions: RRIP_1991A
Unable to identify CD-ROM format.
VFS: Can't find an ext2 filesystem on dev loop0.

et ça, ça me fait peur. Peut etre qu'il sait juste pas gerer l'utf8. Mais le truc byzare c'est le VFS qui veut monter une stage2.img dans dev loop0 au format EXT2, alors que le stage2.img c'est bien connu, est en squashfs sous Fedora...

C'est pas encore gagné

Merci

bon j'en viens à la conclusion que c'est /usr/bin/runroot qu'il me manque (d'apres le strace)
Si quelqu'un sait où se cache cette commande je suis preneur

bon d'apres cdinstall.c d'anaconda, c'est surement parcequ'il me manque le stage2.img qui devrait être généré par buildinstall. Mais comme celui merde monumentalement c'est pas gagné

il doit me manquer une connerie à tout les coups

bon ok ça c'est fait, c'etait bidon un mauvais ks.cfg

là maintenant l'installeur anaconda reconnait pas le CD, ça doit etre 3x rien (enfin jespere).

J'approche du but

Merci pour les info sur le boot.cat il est tout simplement crée automatiquement par mkisofs, mais uniquement dans l'ISO c'est pour ça que j'minquietais

Ce qui m'inquiete toujours c'est les erreurs lors du buildinstall d'anaconda, ça me construit qq image quand meme, mais au boot du cd c'est pas encore ça. Il tente de charger un noyau linux alors que j'ai que du vmlinuz, et ça chie grave apres, ça lance pas du tout anaconda. Mais bon jdois pas etre tres loin

avec redhat on a un script qui s'appelle implantisomd5 qui s'occupe de calculer un md5sum pour la verification et de l'ajouter dans l'iso (bien sur il doit pas s'agir du md5 de l'iso en elle meme vu quelle est modifiée pour inserer le md5, mais je sais pas de quoi exactement )

Je comprend mieux pourquoi tu étais si occupé :)

Ce livre à l'air pas mal du tout, illustré et avec pas mal d'exemple ça à l'air bon

no problem jvais demander

j'ai un autre point d'ombre qui va venir juste apres la construction de l'installeur, c'est la frabrication des ISO, notement concernant le fichier boot.cat. Si jme trombe pas ce fichier indique les kernels bootables présents sur le cd, donc si j'en rajoute/enleve jsuis bon pour le refaire, mais je trouve null par de la doc à son sujet :(

Mais bon jdois deja resoudre mon probleme de buildinstall d'anaconda

bon jviens de regarder Blag linux et ils se basent sur une fedora < à la version 5 (vu qu'ils utilisent genhdlist qui est remplacé par les metadonnes de yum maintenant). Mais ya quand meme des choses interessantes (et d'autres liens fournit)

merci pour votre aide et pour les liens, ça m'a l'air d'etre du bon (et Blag linux je connaissais pas, jvais aller jetter un oeil ou deux)

Une fois ce probleme surmonté c'est clair que jvais partager mon experience, surement sous la forme d'un journal expliquand comment customiser une fedora (jpourrais deja ecrire le truc sur construire une RHEL from SRPMS)

Le lycée léonard de Vinci à Melun propose depuis 2000 un BTS informatique de gestion, le tout uniquement sous GNU/Linux

apparement dans mon ~/.rpmmacros j'ai ça a viré %debug_package %{nil}
Jvais tester

s/connection/connexion/g

Au minefi on aime les stats, par contre au minefi on sait pas tellement bien configurer les alteons. Ces machines qui servent de frontal pour equilibrer la charge par ex, sont configuré en mode proxy, si bien que sur une partie de la plateforme web, les logs d'apache ne voient que 4 pauvres IP taper des requetes. Des millions de hits, mais seulement 4 ip... et ça, ça fait des stats de merdes en interne...

Bravo et merci pour tous ces commentaires, jviens de passer d'un rpm de 53Mo, a un rpm de 8Mo!! et jtrouve que c'est la classe, mais bon j'en serais pas là si vous m'aviez pas aidé

Et voici la liste des coupables:

le --disable-strip fournit dans le mozconfig des src.rpm (redhat/fedora/SL etc)
j'ai aussi précisé --enable-extensions=default car peut etre que sans ça il compile une floppé d'extensions... mais deja avec le stripping celles ci ont du bien maigrir.
J'ai ensuite désactivé certaines features dont j'avais pas besoin qui sont surement compilées par defaut

Encore merci :)

wow merci ça va bien m'aider