systemx

Aller au contenu | Aller au menu | Aller à la recherche

jeudi, juillet 4 2013

Fedora 19 et Korora 19 - Upgrade report


Le chat étant sorti de sa boite, j'ai mis à jour une fed 18 => 19 en suivant ce tuto.
FC19 -  Schrödinger's cat Cette fois un nouvel (encore un) outil fedora-upgrade est proposé pour faire la mise à jour qui évite la double mise à jour avec fed-up.
En lisant les notes je découvre un programme bien utile "rpmconf" qui permet de mettre à jour les fichiers de configuration systeme qui avaient été modifié par les mise à jour.
Un équivalent de etc-update de gentoo, je suis néanmoins supris de voir des fichiers qui me sont complétement inconnus sortir dans la liste du check et surtout je me demande vraiment pourquoi ce n'est pas intégré à yum ou autre rpm.
Ensuite une fois le système backupé et nettoyé je lance la mise à jour.
C'est parti pour la méga mise à jour :
Install      27 Packages (+98 Dependent packages)
Upgrade    1404 Packages
Remove        2 Packages
Downgrade     3 Packages

30/40 minutes plus tard quelques questions rpmconf, grub-mkconfig ... et reboot.

Je dois avouer que c'est la meilleure upgrade de fedora à ce jour.
Pour Korora fedora-upgrade ne fonctionne pas et j'ai donc procédé via fedup, qui a planté après pas mal de temps à cause des repos virtualbox, j'ai donc mis enable à 0 pour virtualbox.repo et tout s'est bien passé.
Par contre c'est à l'ancienne avec un reboot ou la machine mouline en console pendant 1 heure ...
Pas terrible mais ca fonctionne.

mardi, juillet 2 2013

Salt Stack - Automatisation en python


Salt Stack est un logiciel d'automatisation de taches similaire à Puppet.
Puppet est très intéressant mais un peu complexe à mettre en place, Salt a de gros avantages tels que la simplicité et la souplesse.
Par contre cette simplicité a pour pendant une certaine confusion à la première mise en place.
Voici les concepts et la mise en place d'un config pour automatiser les post installation de distro sur un poste multiboot.

  1. State
  2. Salt utilise les "state" qui sont en fait des séquences déclaratives qui seront ensuite appliquées aux machines cibles.
    Par défaut Salt utilise un mode client/server mais peut aussi etre utilisé en stand alone.
    Le mode client/server s'installe de facon similaire à Puppet avec un echange de certificats entre le maitre et le client (appelé minion dans salt).
    Je ne rentre pas dans les détails qui sont documentés maintes fois mais oriente le billet sur la pratique un peu plus avancées.
    En pratique on défini le repertoire source des configuration qui doit contenir un fichier top.sls qui pourra être appelé via le state.highstate :
    • En mode master/minion
    • salt '*' state.highstate
    • En mode standalone
    • salt-call state.highstate

  3. Grains
  4. On peut ensuite interagir avec des variables définies dans le système (à la manière de facter sous puppet) grâce au grains.
    La encore on a beaucoup de souplesse pour créer ses propres grains, je définie une catégorie dans /etc/salt/minion :
    grains: type: work
    Ca me permettra ensuite de faire un profil "boulot" et un profil "home" simplement.
    On peut ensuite questionner ce "grain" :
    salt-call grains.item type
    Ou bien dans le fichier top.sls :
    base:
      'type:work':
        - match: grain
        - work

    Si le grain 'type' est work on va exécuter le state work, il faut donc que il existe un sous répertoire work dans lequel on a un fichier init.sls.
    Ce fichier init.sls sera équivalent au top.sls de la racine pour ce "state".
    On peut ensuite appelé ce state individuellement par :
    salt-call state.sls work

  5. Template/Pillar
  6. Afin d'apporter un peu d'intelligence au langage descriptif salt utilise un systeme de template appelé jinja2. Par exemple on definit un pillar pour les package à installer en fonction des os.
    On définit le pillar dans /etc/salf/minon :
    pillar_roots:
      base:
        - /vagrant/pillar
    Dans ce repertoire on définit un top.sls :
    base:
      '*':
        - pkgnames
    
    Puis dans /vagrant/pillar/pkgnames.sls :
    pkgdef:
      {% if grains['os_family'] == 'RedHat' %}
      apache: httpd
      {% elif grains['os_family'] == 'Debian' %}
      apache: apache2
      {% endif %}
    Ensuite dans le apache.sls (dans les salts /vagrant/salt/work dans mon cas):
    apache:
      pkg.installed:
        - name: {{ pillar['pkgdef']['apache'] }}
    De la même manière on peut tester les configurations pillar :
    salt-call pillar.get pkgdefws:firefox
    On va chercher la valeur firefox dans le groupe pillar pkgdefws (package definition workstation).

  7. Modules
  8. Afin de pouvoir gérer les states salt fournit un grand nombre de modules natifs simple d'accès.

    A noter que le templating est aussi accessible hors des pillar directement dans les states standards.

  9. Autres outils
  10. Accessiblité de la doc :
    La command salt-call sys.doc permet de voir la documentation sur tous les modules.
    On peut voir ensuite un module particulier :
    salt-call sys.doc user
    
    Cela ressemble un peu au fonction pydoc bien pratique.
  11. Masterless
  12. On peut tout utiliser en local en configurant Salt en mode sans maitre.
    Il faut mettre cela dans le /etc/salt/minion :
    file_client: local
    Puis lancer les commandes avec --local :
    solydxk-x64 ~ # salt-call --local user.info root
    local:
        ----------
        fullname:
            root
        gid:
            0
        groups:
            - root
        home:
            /root
    ....
    
    Pour declarer le repertoire source des sls :
    file_roots:
      base:
        - /srv/salt/local
        - /srv/salt/pillar
    
    Il faut mette un top.sls dans local, on peut mettre un toto.sls dans pillar pour faire des fichiers de conf.
    Puis on peut en local :
    salt-call --local state.highstate
    Salt est aussi orienté lancement de commande en ligne vers des groupes prédéfinis, on peut aussi gérer des authentifications externes afin de donner des permissions sur le lancement des différents "states". Voir cette page.

Conclusion :
Salt semble vraiment simple à utiliser et puissant après un minimum d'habitude.
La syntax Yaml est cependant un peu trop succinte et peut preter à confusion, il font donc bien découper ses fichiers selon les fonctions.
Le gros point fort est la simplicité de faire des choses avancées, le grand nombre de modules natifs existants et pour ceux qui aiment sa nature pythonienne.

lundi, juin 24 2013

Solydxk - Test


Toujours à la recherche d'un bonne distro debian sous KDE, me revoilà à installer SolydxK.
Nom etrange, boot cd au look aux tons gris pales, sans être exceptionnel plutôt sobre et agréable avec un bon rendu Firefox.
Juste petit défaut car on ne peut pas changer le clavier en type US sans passer par les menus KDE mais continuons.
Tout se passe très bien, je ne sais quel installeur ils ont pris mais c'est simple (trop ...) et propre.
Le temps de l'installation, je regarde les repos et je vois que ils ont les leurs (à la différence de aptosid et consort).
Ca me plait plutôt car ils peuvent sélectionner et créer une distribution originale, d'ailleurs on en profite d'abord par l'utilisation de firefox et thunderbird au lieu des icedove et l'autre ersatz !
Pendant l'installation je peux écouter de la musique avec une vidéo sur un site d'info ... plutôt réussi.
Pour le fun, l'install en vue 3d :
install 3d Pourtant malheur l'installation semble être au point mort...
Je pense que c'est parceque j'installe sur une partition qui contient déjà des données qu'il est perturbé, je formate cette partition (adieu Rosa) et hop c'est reparti, installation en 15 minutes sans soucis.
Reboot (grub de base sans custo mais il retrouve toute les infos), installation de puppet, git, resynchro des repos et post install :
git clone https://github.com/manifestonosuke/Puppet
puppet apply site.pp 
C'est bien d'être chez debian car on tout au niveau système, ils n'ont pas été radins sur les package chez solyd non plus.
J'apprécie vraiment les firefox, virtualbox, chromium, bumblebee même le méchant skype, tout y est .
On peut toujours pinailler sur l’utilisation de ces satanés UUID mais c'est presque parfait.
Sinon il y a quand même un gros bémol, on est dans du debian et les packages sont vieux (on est pourtant en jessie/sid donc les dernières version de dev ...)
KDE 8.4, kernel 3.2 ... ca manque de peps et ca peut poser des problèmes sur des machines recentes !
Les repos me sembent aussi un peu lents.
Par contre ca s'install très bien, ca me semble très stable et bien fournis, le réve pour ceux qui ne sont pas trop regardant sur la version des logiciels.
C'est pas pire que la mise à jour systématique des kernels sous aptosid ...et surtout plus esthétique (le rendu graphique dont firefox est vraiment bon) et facile d'utilisation.
Il faut garder à l'esprit que le but de cette distribution est de fournir une distro stable, securisée et simple.
Je vais continuer à y venir de temps en temps pour voir sur la durée mais l'objectif me semble réussi.

La distro debian la plus aboutie ça semblait pour si simple ...

mercredi, juin 19 2013

Mise à jour Rosa/Mageia - Comment que c'est censé se passer ?


J'ai été un peu confus sur la methode de mise à jour Rosa mal documentée.
Apparement il faut :
urpmi.removemedia -a
urpmi.addmedia --distrib --mirrorlist '$MIRRORLIST'
urpmi --auto-update
Ca me donne :
[root@Rosa64 ~]# urpmi.addmedia --distrib --mirrorlist '$MIRRORLIST' adding medium "main" adding medium "main updates" .... adding medium "restricted updates" adding medium "Restricted32" ... $MIRRORLIST: media/../../i586/media/restricted/release/media_info/synthesis.hdlist.cz $MIRRORLIST: media/../../i586/media/restricted/updates/media_info/synthesis.hdlist.cz
[root@Rosa64 ~]# urpmi --auto-update                                                                          
medium "main" is up-to-date
medium "main updates" is up-to-date
blah blah blah blah blah ....
medium "Resctricted32 Updates" is up-to-date
Et enfin une question que je me posais déjà depuis des années :
In order to satisfy the 'python-distribute|python-distribute|python3-distribute|python-distribute|python-distribute|python3-distribute' dependency, one of the following packages is needed:
 1- python3-distribute-0.6.35-3-rosa2012.1.noarch: Python Distutils Enhancements (to install)
 2- python-distribute-0.6.35-3-rosa2012.1.noarch: Python Distutils Enhancements (to install)
What is your choice? (1-2) 1
Puis celle ci aussi ...
In order to satisfy the 'libjawt.so()(64bit)' dependency, one of the following packages is needed:
 1- lib64gcj13-4.7.3_2012.10-3.1-rosa2012.1.x86_64: Java runtime library for gcc (to install)
 2- java-1.7.0-openjdk-1.7.0.1-2.0.3-mdv2012.0.x86_64: OpenJDK Runtime Environment (to install)
 3- java-1.6.0-openjdk-1.6.0.0-26.b24.1-rosa2012.1.x86_64: OpenJDK Runtime Environment (to install)
 4- classpath-0.97.2-7-rosa2012.1.x86_64: GNU Classpath, Essential Libraries for Java (to install)
What is your choice? (1-4) 2
Ensuite j'ai eu des centaines de megs de mise à jour et tout s'est bien fini.

J'ai de plus regardé du coté de Mageia où j'ai eu les même mise à jour, comme j'ai pas envie de me mettre au russe et que les 2 distros sont assez semblables, j'ai décidé que Rosa passera à la moulinette du format pour une nouvelle remplacante.
Par contre ne peuvent-ils pas éviter ce genre de question dont personne (ou presque) ne se soucis et de faire le choix des composants logiciels ...
Y a donc plus guère que sur ubuntu et fedora que les mise à jour sont galère ?

jeudi, juin 13 2013

Mise à jour Arch - Intervention manuelle


J'utilise différentes distros pour comparer et voir comment elles se comportent sur le long terme.
Je vais noter les différents problèmes de mise à jour que j'ai pu avoir ...
Je suis Sabayon/Arch/Ubuntu/Rosa et Megiea/Korora et cherche une debian compatible sympa mais toujours pas trouvé.

Sur Arch suite aux changements d'architecture de certains repertoires, il faut opérer une opération manuelle pour que la mise à jour puisse être faite.
C'est correctement documenté dans la page de news arch.
C'est un peu court en explication sur les commandes :
  • pacman -Qqo/Qm
  • Q = query
    q = silentieux
    o = Appartient (own)
    m = Package "etranger" (qui n est pas dans la base des packages), installé via les AUR par exemple
Pour moi ca c'est passé sans complication mais pour les amateurs de AUR et autres packages non classique ça peut être casse gueule.
Du arch quoi !
  • Difficulté = 3
  • Criticité = 6
  • Explication = 9

vendredi, mai 24 2013

Vérifier les certificats SSL


Lorsque l'on recoit des certificats SSL on se retrouve avec des machins remplis de trucs chiffrés.
Difficile parfois de vérifier que tout concorde et quel est le pendant de quoi.
On peut cependant vérifier si les 3 morceaux de la chaine de construction des certificats est correcte en utilisant la commande open ssl.
Il suffit de vérifier le "modulus" (clé mathématique de chiffrement) de chaque élément, comme cette clé est longue on créé un hachage md5 plus concis.
Le nom des fichiers n'a pas d'importance mais pour pouvoir scripter on utilise un nom "domain.etiquette.type" où :
  • x509
  • Le certificat réél
  • req
  • Le CSR utilisé pour faire la requete
  • rsa
  • La clé privée générée au moment de la création du CSR
Dans mon cas j'ai :
 %  ls * 
domain.cert.x509  domain.csr.req  domain.priv.rsa
 %  for i in $(ls) ;  
do 
T=$(echo $i | awk -F '.' '{print $NF}') 
echo $T 
openssl $T -noout -modulus -in $i | md5sum 
done 
x509
1af05ed76582f9ee8d15b84d008a315c  -
req
1af05ed76582f9ee8d15b84d008a315c  -
rsa
1af05ed76582f9ee8d15b84d008a315c  -
 %  ls
On vérifie donc bien que les 3 éléments concordent. Pour voir ce que contient le certificat :
 %  openssl x509 -noout -text -in domain.cert.x509  
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            70:a8:04:93:a2:4d:01:fc:f2:4d:4e:9f:4c:43:cf:3e
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 International Server CA - G3
        Validity
            Not Before: Apr  8 00:00:00 2013 GMT
...
Plus d'info sur la manipulation des certificats sur cette page.

jeudi, mai 23 2013

Debian - install en ligne de commande


Ca faisait longtemps que je voulais tester une install debian en mode ligne de commande d'un linux installé.
Pour ce faire il faut un deboostrap qui un embryon d'OS pour installer via un chroot, un peu comme un stage3 de gentoo.
Il est accessible en package via yum (je suis sur une korora/fedora).

[22:01] root@localhost ~ # yum install debootstrap
Je vérifie mes partitions :
[22:13] root@localhost ~ # blk 
/dev/sda1            OS    
/dev/sda4            data 
/dev/sda6            Ubuntu 
/dev/sda7            Sabayon 
/dev/sda8            Arch   
/dev/sda9            Manjaro 
/dev/sda10           Suse  
/dev/sda11           ROSA 
/dev/sda12           Korora
Je n'utilise plus ni manjaro ni ROSA ...
Je choisi donc de remplacer ROSA sur /dev/sda11
je reformate et le monte sur le repertoire temporaire /mnt/Debian
C'est la partition d'installation de notre nouveau systeme.
[22:20] root@localhost ~ # e2label /dev/sda11 Debian     
[22:22] root@localhost ~ # mkfs.ext4 /dev/sda11 
[22:22] root@localhost ~ # mkdir /mnt/Debian
[22:23] root@localhost ~ # mount /dev/sda11 /mnt/Debian/
Je pars sur une version SID (developpement) :
[22:23] root@localhost ~ # debootstrap --arch amd64 sid /mnt/Debian/ \
http://ftp.debian.org/debian/
I: Retrieving InRelease
W: Cannot check Release signature; 
keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg
I: Retrieving Packages
I: Validating Packages
....
I: Configuring libc-bin...
I: Base system installed successfully.
Ca dure une dizaine de minutes puis on peut continuer.
Un système de base est installé dans /mnt/Debian et on peut donc placer notre racine dans ce repertoire.
On ajoute les entrées pour / et la swap dans /etc/fstab.
[22:24] root@localhost ~ # mount -t proc /proc  /mnt/Debian/proc
[22:24] root@localhost ~ # LANG=C.UTF-8 chroot /mnt/Debian/ /bin/bash
root@localhost:/# export PS1='New Deb  # '
New Deb  # apt-get install makedev
New Deb  # cd /dev
New Deb  # MAKEDEV generic
New Deb  # New Deb  # echo '/dev/sda11 / ext4 defaults 0 ^C >> /etc/fstab 
New Deb  # echo '/dev/sda5       none    swap    sw        0       0' >> /etc/fstab 
New Deb  #
Il faudrait à ce niveau configurer la partie réseau mais étant en wifi je passe pour le moment.
Je ferais ca avec networkmanager et l'environement graphique.
On a fait le plus gros, il faut ensuite faire le plus fin c'est à dire la conf du système.
New Deb  # echo Debian64x > /etc/hostname
New Deb  # dpkg-reconfigure tzdata
New Deb  # aptitude install locales console-setup
New Deb  # dpkg-reconfigure locales  ## Choisir UTF8 en_US.UTF-8 + fr_FR.UTF-8
On passe à l'installation du kernel : 
New Deb # apt-cache search linux-image alsa-base - ALSA driver configuration files linux-headers-3.8-1-amd64 - Header files for Linux 3.8-1-amd64 ... linux-image-3.8-2-amd64 - Linux 3.8 for 64-bit PCs linux-image-3.8-2-amd64-dbg - Debugging symbols for Linux 3.8-2-amd64 l... New Deb # apt-get install linux-image-3.8-2-amd64
Enfin grub pour le boot loader :
New Deb  # apt-get install grub2 grub2-splashimages
ATTENTION : Cette étape va remplacer votre grub si vous choisisser d'ecrire grub sur /dev/sda Comme on est en install via un autre OS ca se répare vite de l'OS hôte (grub-mkconfig et grub-install). On aurait bientôt fini si il ne fallait pas installer les logiciels et faire toute la post installation.
Voici le desktop :
apt-get install kde-plasma-desktop kdm network-manager puppet git
A noter que de base l'application ceni est fournie pour gérer le réseau et est très efficace et pratique.

Ensuite il reste un peu de customisation mais le systeme est fonctionnel.
Pour avoir un installeur un peu plus graphique on peut lancer le selectionneur de package par :
tasksel install standard
De mon coté je lance ma post install via puppet et tout roule à peu près.

  • Conclusion
  • L'install est plutôt simple au final surtout avec tasksel par contre il y a peu de customisation et la finition n'est pas au top coté graphique.
    Bien évidement il faut tout configurer mais le résultat est nettement plus sympa sur une arch ou gentoo pour le même type d'OS.
    Il en reste que le choix du nombre de package est impressionnant, que sans aucun doute ca marche très bien mais ça manque vraiment de personnalité, c'est vieillot (même en sid KDE) est en 4.8.4 et d'un petit truc qui fait un desktop que l'on a envie d'expérimenter (dans tous les sens du terme) !
    Ca doit par contre convenir aux gens moins pressés d'avoir les nouveautés et qui aiment se faire un système au petit oignons. Par curiosité je vais allez voir ce que propose les dérivés genre aptosid, j'aimerai bien me trouver une distro basée sur debian mais customisée à la Sabayon.

Comme ennui j'ai eu uniquement :
New Deb  # ldconfig 
ERROR: ld.so: object '/usr/lib64/libXft-infinality/libXft.so.2' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/usr/lib64/freetype-infinality/libfreetype.so.6' from LD_PRELOAD cannot be preloaded: ignored.
Qui est corrigé par :
New Deb  # unset LD_PRELOAD
New Deb  # ldconfig
J'ai pas trop cherché dans le détail.

Mageia - Test


Un essai de Rosa linux m'avait fait revoir mon opinion sur Mandriva.
Je profite donc de l'arrivée de Mangeia V3 pour voir si le père vaut aussi bien que le fils.

Ayant pris le premier DVD, je me suis retrouvé avec l'installeur en mode console, c'est peu pratique mais finalement l'installation s'est bien déroulée.
Il y a plus d'options que ce que nous donne les distro récentes, le mode de partitionnement est bon et ne fait pas de choses inutiles.
Etant donné que c'est le même que Rosa, j'ai eu très peur !

L'installation est un peu longue affichant 26 minutes d'attentes au dernier "suivant".
Au reboot grub est installé (l’ancêtre version 1 !!!) mais n'a découvert quasiment aucune autre distro de mon PC.

Au reboot je me connecte sur le desktop par défaut plutôt sympa sans être très original.
Le KMenu est celui dit classique qui ressemble au vieux menu KDE3, dommage !
Je cherche ensuite à finaliser l'installation via mes scripts puppet.
Je me retrouve à checher la config de repos, ne trouvant pas de doc qui m'aide à les choisir, j'utilise la configuration graphique qui quand même peu intuitive !
Au moins 30 repositories différents, ca veut dire quoi tout ca ?
mageia2.png
C'est documenté mais tout de même un peu compliqué.
Je bricole ensuite tout ca (urpmi.update et urpmi puppet3) pour installer l'agent qui me permettra de faire ma post install.
Une erreur de ma part me fait desinstaller puppet3 pour installer puppet (2) et je me retrouve bizarrement sans ruby ...
De même en supprimant un driver X11 il me propose de supprimer x11-driver-video, ce que je fais.
Il me propose ensuite de supprimer tous les drivers X11, ceux ci étant orphelins (de x11-driver-video) ...
Autre bug, je me retrouve avec des agents gpg lancés alors que l'utilisateur n'est pas connecté.
[root@localhost Puppet]# ps -fp 7251
UID        PID  PPID  C STIME TTY          TIME CMD
pierre    7251     1  0 20:32 ?        00:00:00 gpg-agent --keep-display --daemon --write-env-file /home/pierre/.gnupg/gpg-agent-info
Quand même le plus gros problème reste la version de grub qui est en version de 1987 ou qque chose comme ca.
C'est un peu scandaleux mais ca se change facilement :
Ca fait bien longtemps que grub est en 1.99 ou 2+.
Impossible à enlever cependant :
[root@localhost Puppet]# urpme grub
La désinstallation du paquetage suivant rendra votre système instable
  basesystem-2-15.mga3.x86_64
Ca évite de se retrouver sans bootloader, il faut donc d'abord installer grub2 et enlever grub.
  • Conclusion
  • Malgré des petits bug vraiment peu pénalisants, la distrib se tient très bien.
    Les packages sont pas trop vieux mais peu mieux faire firefox), peut-etre cependant un gage de stabilité.
    Par contre même si il y a des bonnes idées dans le système de package, la gestion des media est vraiment pénible graphiquement et manuellement pas mieux.
    Ce qui peut être très ennuyeux aussi c'est la gestion des dependances qui me semble un peu douteuse.
    Quelques choix vieillot mais par rédibitoire sont a regretter (grub2, menu KDE classique ...)
    Grâce à son look et le nombre de ses package et la simplicité d'utilisation, on a une distro qui a une vraie personnalité, de plus communautaire avec bonne doc et forum, ce qui ajoute un cachet sympa.
    Une petite distro sympa pour ceux qui aiment sortir des sentiers battus sans mettre trop les mains dans la technique.

PS : Je passe sur le centre de controle mageia car je n'apprécie pas ce genre d'outils mais à noter qu'il y a une interface d'administration.

dimanche, avril 28 2013

Ubuntu upgrade en 13.04 : La longue marche


Pas vraiment ubuntuteros, je suis pourtant cette distro majeure pour l'éco système linux.
Il y a quelques jours la pop up d'upgrade apparait, je clique ok et 2 bonnes heures plus tard au reboot surprises, surprises.
  1. KDE ne se lance
  2. startkde: Could not start D-Bus. Can you call qdbus?
    J'ai trouvé relativement vite la solution.
    apt-get install qdbus:amd64
  3. Unity instable
  4. Après le login, l'ecran reste noir ou bloqué sur l'image lightDM et tout les settings (déjà peu nombreux) semblent inopérants.
    J'ai cherché pas mal sans solution mais il semblerait que ce soit des problemes optimus/bumblebee.
    Ce package pour gérer les cartes hybrides vient d'un PPA externe, j'entreprends de vider tout ca et me plonge dans une suite sans fin de apt-get remove autoremove purge ... quel bazard pour enlever tout ca !
    Cependant la situation semble empirer, je restore donc la version pre upgrade et enleve une nouvelle fois bumblebee.
    Remove de unity/compiz, reinstallation d'un nouveau kernel (dist-upgrade), reinstall de ubuntu-desktop.
    Mais unity était toujours planté au démarrage. Il reste bloqué après le passage de la mire, dans .xsession-errors je trouve :
    Error: Plugin 'opengl' not loaded.
    J'ai pu faire ressucité unity avec :
    dconf reset -f /org/compiz/ setsid unity
    Au final je retire tous les ppa (sauf garmin) et relance un upgrade manuelle :
    apt-get update apt-get dist-upgrade apt-get install update-manager-core do-release-upgrade -d
    Celle ci se passe au final bien mais dure presque 3 heures.

J'ai vraiment passé du temps la dessus, juste pour une upgrade mineure.
Ca confirme que les ppa c'est vraiment la mouise, les dépendances des packages ubuntu sont parfois vraiment délirants et de manière générale cette distro gère mal les exceptions à son petit monde.
Je note aussi que les écrans virtuels passe à 1 sans crier gare et ce sur un compte existant !
A force de trop vouloir simplifier et forcer ses utilisateurs à suivre se voie, ceux ci risquent de partir.
Une seule chose positive, ce n'est que la partie graphique qui semble avoir eu des soucis.
Pourquoi donc ne passent ils pas en Rolling Release pour en finir avec ces cauchemars de mise à jour.
Ca fait si longtemps que j'ai pas connu ce genre de cauchemar sur Sabayon/Gentoo ou même Arch, alors que sur Fedora, Ubuntu ou Suse on serre les fesses à chaque nouvelle release ...

mercredi, avril 24 2013

Manjaro - 0.8.5 - KDE test


Manjaro a créé un petit buz à la sortie de la 0.8.5, signe de la popularité de arch et du besoin de rendre cette distro un peu moins technique tout en gardant les coté sympa de Arch.
Il y a à mon avis un bonne opportunité à prendre pour ceux qui veulent se faire une bonne petit distro, curieux de voir le résultat j'ai essayé la Manjaro KDE.

L'installation est très bonne, simple, en mode live cd, rien à dire.
Premier étonnement, peu de customisation graphique au premier boot.
Un écran grub orné d'un discret logo Manjaro, pas de splash screen au boot qui laisse la place au log systemd classique.
Ca continue sur KDE ou le login manager et le desktop sont ceux par défaut.
Il faut sûrement chercher dans les versions openbox/xfce pour trouver ce genre de chose.
C'est un peu dommage car ca donne de la personnalité à une distro surtout telle que Manjaro qui n'apporte aucun défi technique.

Ensuite ca se gâte grandement à la première mise à jour ou je tombe sur le même bug que sous arch pour le passage de pacman en 4.1.
looking for inter-conflicts...
error: failed to prepare transaction (could not satisfy dependencies)
:: package-query: requires pacman<4.1
Un fois corrigé, je tombe ensuite sur un autre bug, pacman ne voit plus aucune mise à jour !
Résolu grace à ce post.
Il m'a fallu une bonne demi heure de boulot alors que je connais Arch ....
Quelques remarques sur le reste des tests.
  • Octopi
  • Le package manager maison est ultra classique et de plus ne gère pas les AUR.
  • Kernel
  • A la différence de Arch, par défault on peut installer plusieurs versions de kernel en même temps
    Est ce vraiment une option recherchée par les newbie, quid des upgrades et nettoyages des vieilles versions ?
  • bumblebee
  • La gestion des GPU hybride est inclus en standard mais par contre ca marche pas OOTB (peut etre à cause de nouveau ?).
  • Packages installés
  • A mon avis il y a trop de soft installés par défault kloppy, kmymoney, braindump. Grâce à Arch on reste cependant sur un espace disque restreint.

En bref, même si Manjaro n'a pas de gros défault par rapport à une Arch, elle n'en a que peu d'avantages.
Le gros plus est l'installation graphique qui est propre et bien faite (quoi que trop simple) mais est-ce vraiment utile vu que de toute façon il faudra passer par la ligne de commande pour les problèmes (certes peu nombreux) de mise à jour ou bien même pour installer les package venant des AUR (à noter que la compil à planté quand j'ai tenté d'installer bespin).
Manjaro pourrait devenir intéressante mais il faudra qu'elle devienne beaucoup plus mature.
Par exemple, corriger les problème classiques d'upgrade arch avant de les propager dans ses propres repos, proposer un choix important de AUR en package natifs (un peu comme Calculate/Gentoo), faire plus de customisation graphique sur TOUS les environements proposés et enfin faire un outil graphique de gestion de package qui apporte quelque chose de nouveau.
Par contre la communauté semble très active ce qui est un gros gros plus et qui lui permettra peut-être d'atteindre ce niveau de maturité.

mardi, avril 16 2013

Fedora grrr Redhat

RedHat étant un acteur important de l'écosystem linux voir le géniteur de l'opensource dans les datacenter, je suis régulièrement ce qui se passe sous fedora qui est leur bouillon de culture et qui permet de découvrir pas mal de nouvelles choses.
Cependant cette distro est vraiment pas confortable au quotidien car les softs non redhat sont très mal supportés et on doit invariablement passer par l'ajout de repos ou bien la chasse aux rpms sur internet.
Dans mon aventure sur Kokora j'avais une fois de plus noté l'inflation des repos (entre autre pour les produits google) et les problèmes de cohérence de l'ensemble du système.
Travaillant avec vagrant pour faire des usines de test Redhat, j'ai fait un tour sur fedora ou bien évidement le package n'existait pas (alors qu'il est dispo sur ubuntu/gentoo par exemple).
Ensuite l'intégration a vraiment confirmé cette impression de pas fini et du peu de considération de redhat pour les pauvres péquins comme moi.
En gros pour creer un modele de box vagrant il faut packager une virtualbox avec la command vagrant package qui sous fedora créé un fichier temporaire dans /tmp.
Or depuis F18 /tmp est un filesystem tempfs qui fait par defaut la taille de la moitié de la mémoire.
[@fedora .vagrant.d]$ df -h /tmp
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           968M   28K  968M   1% /tmp
La creation de la box plante lamentablement et plombe /tmp, il faut en général quelques GB pour creer les package.
De plus virtualbox est pas packagé, il faut ajouter les repos, tout reconstruire à la mimine.
Il y a bien de moyens de changer ce comportement mais au final travailler sous fedora avec virtualbox/vagrant c'est un cauchemar.
Je retourne sous gentoo, sabayon ou même ubuntu où tout est très bien packagé et fonctionne sans problème.
Il reste à mon avis une belle place pour une distro basée sur fedora qui intégrerait bien tous ces composants (et d'autres) suite à la mort fuduntu (encore du aux abus de pouvoir de RH entre gnome/sytemd). car quoi qu'on en dise RH reste le plus gros acteur Linux en entreprise.
Toutes ces reflections me font d'ailleurs penser à la belle place que peuvent trouver Ubuntu ou Opensuse qui font des distributions à la fois orientées enteprises et end user qui sont plus souples et intégrées que le trio boiteux RHEL/CentOS/Fedora.

samedi, avril 13 2013

Virtualbox - Installation pour utilisation CLI


Le but de ce billet est de résumer tous les points que j'ai vu pour avoir une configuration virtualbox complétement contrôlable en ligne de commande avec graphique accessible en VRDP.
Le nom de la VM est guest.

  • Creer un port de connection VRDE
  • Cela permet d'avoir ensuite l'accès à la console car en mode headless impossible de recuperer la console du client lourd.
    La fonctionnalité est fournie avec les extention pack de Virtualbox, à ne pas confondre avec les guest addition.
    Il faut télécharger le pack à cette URL ($VBOXVER est la version virtualbox) :
    http://download.virtualbox.org/virtualbox/$VBOXVER/Oracle_VM_VirtualBox_Extension_Pack-$VBOXVER.vbox-extpack
    Ensuite faire la configuration suivante pour utiliser la fonctionnalité vrde :
    VBoxManage extpack install "fichier downloadé"
    VBoxManage modifyvm guest --vrde on
    VBoxHeadless --startvm guest --vrde config

  • Forwarder port SSH pour le mode NAT
  • La machine arrétée il faut changer les propriétés avec la commande suivante :
    VBoxManage modifyvm "guest" --natpf1 "guestssh,tcp,,2222,,22"
    On pourra ensuite se connecter à la VM avec
    ssh -p 2222 localhost

  • Permettre le server DNS de repondre au requete de l'hote
  • il faut que la VM passe les requetes DNS au guest.
    VBoxManage modifyvm "guest" --natdnshostresolver on

  • Installer le guest addition
  • Cette partie là est à faire sur la machine invitée donc après l'installation.
    Cela necessite une compilation, il faudra donc ajouter les "kernel headers" et autres outils de compilation.
    J'ai trouvé cette page qui détaille bien l'installation.

Ensuite on peut avoir pas mal de details avec les commandes suivantes :
VBoxManage getextradata guest enumerate
VBoxManage showvminfo guest --details
VBoxManage list extpacks
La deuxième commande est particulièrement utile car on peut voir les details VRDP.

On peut aussi voir l'IP de la VM après avoir installé l'ext pack et le VM guest addition.
VBoxManage guestproperty get guest /VirtualBox/GuestInfo/Net/0/V4/IP | awk -F ':' '{print $2}'

Enfin en cas de plusieures VM tournant sur le même hôte, on pourra gérer les différents port VRDP en utilisant un "range" de ports à la declaration :
VBoxManage modifyvm guest --vrdeport 3333-3353


Enfin pour bien ranger ses vm dans un répertoire donné on peut faire un :
VBoxManage setproperty machinefolder /data/VirtualBoxVm/

Je trouve ca vraiment stupide de mettre des fichiers de plusieurs gig dans un fichier caché de la home ....

J'ai compilé tout ca dans mon script de management en mode cli de virtualbox.
Il y a maintenant un version python3 de la chose plus sympa à utiliser : vb.py

vendredi, avril 5 2013

Comment Sauvegarder/restaurer/deplacer ses distro/partitions linux

Le but de ce billet est de faire un point sur la politique de sauvegarde, linux et les partitions afin de ne plus craindre de perdre son boot, son OS ou ses données.
Ca m'a été très précieux suite aux taquineries de l'installeur de Rosa.
Ce billet explique comment sauvegarder, restaurer et deplacer son OS/partition et accessoirement ses données.
Il se base sur un poste avec plusieurs linux en utilisation desktop, installés chacun sur une unique partition et les données dans une autre. Le boot est sous grub. voir le billet sur les install multiples.
  1. Sauvegarde OS
  2. Pour sauvegarder une partition entière, j'ai trouvé l'utilitaire fsarchiver qui corresponds parfaitement à ce besoin.
    Les partitions font 15/20GB et sont toutes nommées (via e2label), Le fichier de sortie est appelé "LABEL-Partition.fsa" (par exemple Korora-sda12.fsa).
    La commande à lancer pour chaque partition sera du type :
    fsarchiver savefs -o /backup/Korora-sda12.fsa -v -j2 -z 1 /dev/sda12
  3. Sauvegarde MBR
  4. Il faut de plus bien sauvegarder la table des partitions du disque au cas ou elle serait perdue.
    C'est un grand classique que celle ci soit effacée par un programme sans pourtant avoir de perte de données.
    Le résultat est d'avoir tout perdu (on peut essayer testdisk) alors que c'est très simple d'en faire une sauvegarde.
    Comme deux précautions valent mieux qu'une j'utilise 2 commandes dont je sauvegarde la sortie :
    dd if=/dev/sda of=dd.out bs=512 count=1
    sfdisk -d /dev/sda > sfdisk.out
  5. Restauration sans perte de la table de partition
  6. Il suffit booter si un autre Linux ou un media externe de restaurer le fichier via fsarchiver.
    fsarchiver restfs  Korora-sda12.fsa id=0,dest=/dev/sda12
    Si la partition destination est différente de la paritition source, il faudra éditer le fichier /etc/fstab et eventuellement les fichiers grub si ils ont étés customisé avec des nom de partition.
    Pour la fstab il faut changer la partition d'entrée qui est le premier élément (/dev/sda12) :
    /dev/sda12 / ext4 defaults,acl 1 1
  7. Restauration avec perte de la table de partition
  8. Si la partition du disque disparaît, j'applique les commandes sfdisk/dd inverses pour reprendre mon partitionnement original.
  9. Récupération de grub
  10. Il est très simple de reconstruire grub après par exemple un déplacement de partition :
    grub-mkconfig -o /boot/grub/grub.cfg
    grub-install  /dev/sda
    
    Cependant ca se complique si on doit booter sur un média externe (type livecd) ou que l'on veut restaurer grub à partir d'une partition sur laquelle on ne peut booter.
    Dans ce cas, on utilise un chroot qui permet de deplacer temporairement le / du système.
    L'exemple suivant permet de reconstituer le grub pour le disque à partir du linux de la partition 12.
    mount /dev/sda12 /mnt/
    mount -t proc none /mnt/proc
    mount -o bind /dev /mnt/dev
    mount -t sysfs sys /mnt/sys
    chroot /mnt/ /bin/bash
    grub-mkconfig -o /boot/grub/grub.cfg
    grub-install  /dev/sda
    exit
    umount /mnt 
    reboot
    En gros on met la parition cible sur le repertoire /mnt, ensuite les autres mount servent à utiliser les fichiers dynamiques de l'OS en cours d'execution dans la partition qui sera "chrootée" et enfin deplacer la racine dans cette partition puis installation de grub en utilisant les données de celle ci.
    Si il y a des partitions lvm il faut faire avant le mount :
    vgchange -a y
    lvscan
    
  11. Deplacement de paritition
  12. De la même manière il est très simple de déplacer son OS de partition.
    On boot sur un autre OS, on fait le dump, on le restaure sur une autre partition via fsarchiver.
    fsarchiver restfs  Korora-sda11.fsa id=0,dest=/dev/sda12
    Ensuite il faut monter cette partition et changer la fstab pour changer la reference du /
    On peut regenerer grub simplement avec :
    grub-mkconfig -o /boot/grub/grub.cfg
    grub-install /dev/sda 
    
    Par contre si on boot sur un media externe, il faudra passer par un chroot.

Notes :
  • Au final tout cela est très simple, un peu de pratique et cela semblera très naturel.
  • Les commandes grub peuvent etre un peu différentes selon les distro comme grub2-mkconfig ou install-grub2.
  • fsarchiver permet de sauvegarder plusieurs partitions dans un même fichier, utile en cas de systeme installé avec cette configuration.
  • J'ai ecris ce script qui automatise les sauvegardes (en fonction du type de part, montage, MBR ...).


  1. Sauvegarde des Données
  2. Pour les données afin qu'elle restent accessible sous forme de file system sur disque externe, j'utilise rsync, il y a beaucoup de doc sur cette commande, je ne m'étant pas sur le sujet.
    Par rapport à fsarchiver qui prends une image à un instant t, rsync copie des données selon pas mal de critères.
    J'ai fais un script qui utilise un fichier de propriété pour sauvegarder les repertoires importants (home,musique, photos ...).

dimanche, mars 24 2013

Un springbok chez les chinois ou ubuntu et l'alliance au sulfur


Un nouvelle est passée plus ou moins inaperçue dans le blogonet opensource française mais me semble pourtant un gros coup joué par Ubuntu.
Cannonical a passé un accord avec le gouvernement chinois pour créer un OS national basé sur Ubuntu adapté à la langue chinoise mais aussi à divers projets.
Un laboratoire des technologies open source sera créé qui réunira les intérêts des différents acteurs.
Il y a aussi une partie destinée à gérer les constructeurs de SW et HW chinois qui sont à la fois légions, compétents et surtout dominateurs sur le marché mondial des PC.
La première version est prévue pour 2013/04 et s’appellera Kylin Ubuntu linux.
Bien évidement on peut craindre le pire d'un gouvernement qui ne se cache pas d'espionner ses ouailles et l'utilisation d'un OS ubuntu à ces fins seraient pour le moins mauvais pour Ubuntu.
Cependant étant open source, tout type de logiciels espion serait vide dévoilé, rendant peut probable l'utilisation de linux pour faire un espionnage à grande échelle.

Avec son milliard et quelque de d'habitants, un déploiement à grande échelle Ubuntu dans ce pays pourrait propulser cet OS dans une autre dimension avec à la fois une émulsion positive utilisateurs/constructeurs/vendeurs mais aussi dénaturer le produit pour s'adapter à cet immense marché dont les utilisateurs ont très certainement une autre façon de voir l'informatique que les Occidentaux.
La centralisation du pouvoir à la chinoise apporte aussi une force de frappe particulièrement imposante, même microsoft (accusé de corruption en Chine ...) ne peut pas vraiment faire le poids.
Pour le moment difficile de savoir ce que tout ca va devenir mais en tout cas, il est urgent d'attendre un an ou deux pour voir si cela peut influencer le marché de l'informatique mondial.

Quelques liens :
http://www.engadget.com/2013/03/23/china-chooses-ubuntu-for-a-national-reference-os-coming-in-april/
http://www.theregister.co.uk/2013/03/22/china_makes_linux_os_with_canonical_help/

PS : Kylin/qilin ou 麒麟 ou kirin en japonais est un animal mythique du folklore chinois sorte de licorne.

jeudi, mars 21 2013

Owncloud - Ca se bonifie avec le temps

Je viens de migrer mon "owncloud" en 5 minutes chrono.
Ma basedir pour mon vhost owncloud est ow. Attention à la taille du repertoire data.
La mise à jour se déroule comme suit :
mv ow ow4
wget http://download.owncloud.org/community/owncloud-5.0.0.tar.bz2
bzip2 -d owncloud-5.0.0.tar.bz2
tar xf owncloud-5.0.0.tar.bz2
mv owncloud ow5 
cp -rfp ow4/config ow5 
cp -rfp ow4/data ow5 
# Si votre group n'est pas apache 
find ow5 -groups user -exec chgrp www-data {} \; 
# Si le owner est pas apache 
chmod g+w ow5/apps 
mv ow5 ow

Ensuite un ecran de progression de l'upgrade et en quelques minutes, le site est dispo.
Tout de suite il y a une grande différence au niveau réponse, c'est beaucoup plus fluide.
Le menu admin est partie dans le bouton en haut à droite et la barre de menu application a des belles icones.
Ca me rappelle Unity en bleu !
Coté fonctionnalité ca change peu mais c'est vraiment plus fluide et agréable à utiliser.
Par contre il me manque certaines extensions.
Pour corriger la perte de ces extensions, je copie les repertoire de ces applis de mon ancien repertoire ow/apps/ vers le nouveau.
Déloggue logue, puis les activer dans le bureau.
Voilà !
Pour une description plus détaillée => linuxfr.
Enfin une petite image :
owncloud5.jpeg

mercredi, mars 20 2013

Test kororaa 18 beta

Après la déception de opensuse, je continue à cherche une distro systemd/rpm sympa.
Fedora est assez peu adaptée pour un desktop car il faut ajouter un tas de dépos pour avoir navigateurs, codec ...
J'aime bien voir le travail d’intégration des distro linux, connaissant fedora je choisis sa dérivée Korora KDE.

L'installeur anaconda a été revu entièrement et suit la simplification maximum que l'on voit depuis quelques années.
Je n'aime pas trop mais le gros probleme réside dans la module de partitionnement.
Pour y accéder il faut déjà sélectionner install boot device à un premier ecran ce qui porte à confusion.
Ensuite c'est le mystère :
kororaa1.png Je m'y suis repris à 3 fois pour arriver à mes fins et encore de facon, ce fut compliqué.
Il y a pas mal de plaintes sur le net concernant cet installeur, mais bon on le fait une seule fois ...
On finit 2 ou 3 parametres au reboot puis on retrouve le bureau décoré à la sauce Korora plutot sympa.
Sous la capot on retrouve une fedora pure jus avec pas mal de customisation.

C'est clairement orienté desktop.
Le client steam, linphone client SIP, client OwnCloud, google earth, google talk, client twitter, client blog, un client multimedia appelé miro qui melange client youtube, rss, torrent, player de même que beaucoup d'applications multimedias et d'extentions FF installées.
Par contre peu de développement personnalisé, on retrouve les horribles clients system-xxx de redhat en gtk.
Voici la liste (conséquente) des repos après l'installation :
[22:38] root@localhost Puppet (master) # yum repolist
Loaded plugins: etckeeper, langpacks, presto, priorities, refresh-packagekit, refresh-
              : updatesd, security, versionlock
24 packages excluded due to repository priority protections
repo id                             repo name                                  status
adobe/x86_64                        Adobe                                            1+1
adobe-32bit                         Adobe - 32bit                                   1+16
fedora/18/x86_64                    Fedora 18 - x86_64                         33,852+16
google-chrome/x86_64                Google Chrome                                      3
google-earth/x86_64                 Google Earth                                       1
google-talkplugin/x86_64            Google Talkplugin                                  1
korora                              Korora 18 - x86_64                               125
rpmfusion-free/18/x86_64            RPM Fusion for Fedora 18 - Free                  469
rpmfusion-free-updates/18/x86_64    RPM Fusion for Fedora 18 - Free - Updates        308
rpmfusion-nonfree/18/x86_64         RPM Fusion for Fedora 18 - Nonfree               214
rpmfusion-nonfree-updates/18/x86_64 RPM Fusion for Fedora 18 - Nonfree - Updat       216
updates/18/x86_64                   Fedora 18 - x86_64 - Updates                12,641+8
virtualbox/18/x86_64                VirtualBox                                         3
J'aime pas trop l'intégration chrome et autres logiciels avec noms/path peu standard mais surtout il manque certains package importants type bumblebee pour une distro desktop c'est dommage.
Les rpm montrent encore leur limitation car à une update quelques jours après l'install yum crache :
Finished Dependency Resolution
Error: Package: kmod-VirtualBox-3.8.3-203.fc18.x86_64-4.2.10-1.fc18.1.x86_64 (rpmfusion-free-updates)
           Requires: kernel-uname-r = 3.8.3-203.fc18.x86_64
           Installed: kernel-3.7.7-201.fc18.x86_64 (@Fedora 18 - x86_64 - Updates/$releasever)
               kernel-uname-r = 3.7.7-201.fc18.x86_64
           Installed: kernel-3.8.3-201.fc18.x86_64 (@updates)
Je sais pas trop où est le micmac mais ca semble un peu foireux de pas fournir les bonnes versions.
Ca semble corrigé quelques jours plus tard.

Au final Korora n'est guère plus qu'une fedora avec des repos externes et un peu de customisation graphique.
Même si le travail est plutôt bien fait, le rendu très propre cela reste très peu novateur.
On est assez vite limité par les repos même si il y en a un grand nombre, c'est des choix de fedora.
On appréciera les video OOTB et les quelques applications multimedia originales et autres customisation qui couvrent certains défauts de fedora.
C'est une jeune distro, pas mal pour ceux qui veulent du redhat, voyons ce que cela va donner avec le temps ...
Enfin pour voir à quoi ressemble l'interface, le site korora.

dimanche, mars 17 2013

Suse Tumbleweed : super novae de votre distro.

La recente sortie de OpenSuse m'a donné l'occasion de tester l'upgrade opensuse en mode rolling release.
J'étais curieux de voir ce premier passage de version en rpm, c'est vrai que la derniere Fedora s'était miraculeusement passée mais tout de même, que vaut Tumbleweed ?
Je fais le ménage dans les repo car pour installer des softs il faut souvent faire des "one click install" ce qui est très pratique mais rends vos repos incompréhensibles et les upgrades difficiles (genre voulez vous le paquet de tel repo en version x.y ou de celui la en x.y.z ?).
De plus j'avais toujours des repos qui pointaient vers la 12.2 qu'il fallait remplacer par ceux sans version pour bumblebee.
Grand ménage de printemps en suivant ces instructions pour tumbleweed.
Il me reste donc :

linux-59at:~ # zypper lr
#  | Alias                    | Name                     | Enabled | Refresh
---+--------------------------+--------------------------+---------+--------
 1 | Application:Geo          | Application:Geo          | Yes     | Yes    
 2 | KDE:Extra                | KDE:Extra                | Yes     | Yes    
 3 | Tumbleweed               | Tumbleweed               | Yes     | Yes    
 4 | devel:libraries:c_c++    | devel:libraries:c_c++    | Yes     | Yes    
 5 | home:garminplugin        | home:garminplugin        | Yes     | Yes    
 6 | home:pbleser:staging     | home:pbleser:staging     | Yes     | Yes    
 7 | libdvdcss                | DVD Repository           | Yes     | No     
 8 | openSUSE Current OSS     | openSUSE Current OSS     | Yes     | No     
 9 | openSUSE Current non-OSS | openSUSE Current non-OSS | Yes     | No     
10 | openSUSE Current updates | openSUSE Current updates | Yes     | No     
11 | packman-essentials       | packman-essentials       | Yes     | Yes    
Les repos 3 et 11 sont pour tumbleweed (le 11 c est les packages additionnels en mode tumbleweed).
2 pour KDE en version récente, 1,4,5,6 pour mon GPS de jogging Garmin.
7 pour les DVD mais pas sûr que ce soit nécessaire, enfin 8,9,10 sont pour l'OS courant.
Ca reste comprehensible ....
Ensuite attention à la mise à jour, près de 1000 packages mis à jour et pas mal de temps d'électricité (de Fessemheim ??? ..).
Je perds le réseau, ca prends du temps mais un petit restart de networkmanager fonctionne et tout à l'air bon :
linux-59at:~ # more /etc/SuSE-release
openSUSE 12.3 (x86_64)
VERSION = 12.3
CODENAME = Dartmouth
Mais mais au reboot, le systeme explose, systemd ne reconnaît plus ses petits, networkmanager et le réseau en général est en vrac, le système n'arrive même pas à la mire kdm, nis même à un shell exploitable.
J'ai un peu cherché mais n'ayant pas tant de temps, j'ai finalement restauré mon OS.
Je crois bien que sans release officielle de Tumbleweed, on ne me reprendra plus à jouer avec.

vendredi, mars 15 2013

Les poupées au quotidien - l'automatisation à la maison

Dans l'administration système de nouveaux outils de depoiement ont fait leur apparition il y a quelques années.
En opensource bien sûr et qui sont très efficaces pour gérer les changements massifs sur les datacenters mais pas seulement.
Indispensable dans le cloud, ils s'avèrent aussi utilises au quotidien car il savent faire abstraction de l'OS.
Le plus célèbre des outils est puppet (qui a recu un investissement de 30M$ de vmware .... quand on parle de cloud ...).
Puppet est à la fois simple et complexe, le but de ce billet n'est pas de rentrer dans le détail mais de décrire une utilisation pratique pour moi qui teste pas mal de choses.

Je cherchais à faire un script qui installait des packages en faisant abstraction du package manager (yum, apt-get ...), c'est en fait rapidement devenu une usine à gas.
Interessé par puppet, j'ai remarqué que cela fonctionne aussi sans serveur central.
Exactement ce qu'il me faut, je fait donc des profils pour installer les packages que j'utilise sur chaque nouvelle distro que je teste.
Si puppet est dispo, il suffit de faire un fichier de profile :
[root@Rosa64 puppet]# cat utils.pp 
package { "ncftp":
  ensure => installed,
}
package { "fsarchiver":
  ensure => installed,
}
puis de lancer :
[root@Rosa64 puppet]# puppet apply utils.pp 
notice: /Stage[main]//Package[ncftp]/ensure: created
notice: /Stage[main]//Package[fsarchiver]/ensure: created
notice: Finished catalog run in 8.04 seconds

Puppet a bien installé mes packages sans que j'ai besoin de connaitre les commandes systemes (dans mon exemple Rosa/Mandriva).
Il ne me reste plus qu'à aller plus loin en faisant des groupement de package, creation de utilisateurs, gestion sudo ....

Evidement puppet peut aller beaucoup plus loin pour gérer différents type de profil, version de package, versionning de fichier de conf, template de deployement.
Ca se complique alors sérieusement, pour aller plus loin :
Une bonne intro en francais.
Plein de truc aussi en francais qui sentent le vécu.

Il peut s'associer avec des outils tels que foreman (industrialisation complete du cycle de vie des serveurs), vagrant (creation d'usine de virtualbox), capistrano (deploiement) et aussi l'inévitable git pour le versioning.
A noter que la plupart de ces outils tournent en Ruby, le language encore plus hype que python.

mardi, mars 5 2013

Les joies de Arch


Les mises à jour de Arch feront toujours de cette distro, une oeuvre pour les curieux.
J'ai résolu la dernière sans y passer trop de temps mais il faut avouer que c'est pas pour les débutants !
* Symptome :
[root@archx64 ~]# pacman -Syu
:: Synchronisation des bases de données de paquets...
 core est à jour ;
 extra est à jour ;
 community est à jour ;
 archlinuxfr est à jour ;
:: Début de la mise à jour complète du système...
:: Remplacer qt par extra/qt4 ? [O/n] o                                                                        
résolution des dépendances...                                                                                  
recherche des conflits entre paquets...
Erreur : la préparation de la transaction a échoué (la satisfaction des dépendances a échoué)
:: bespin-svn : requiert qt
:: ntrack : requiert qt
Intéressant en regardant les news arch je vois ce qu'il faut faire.
Enlever les packages installés depuis AUR et les reinstaller pour les recompiler.
Les AUR sont des packages maintenus par la communauté qui sont disponible sous forme de source et recompilés à l'installation pour créer un package et l'installer.
Cela enrichis notablement Arch bien que cela induise un grand nombre de package non officiels.
Je recompile (facile via yaourt) donc mais un autre probleme apparait :
-- Did not find automoc4 (Automoc4Config.cmake, install git://anongit.kde.org/automoc). (missing:  AUTOMOC4_EXECUTABLE) 
-- Found Perl: /usr/bin/perl (found version "5.16.2") 
-- KDE4 not found, because Automoc4 not found.
-- WARNING: *** ARGB windows are experimental, performance might suffer ***
-- WARNING: *** Variable shadow pixmap sizes will cause glitches on KWin < 4.7.4 and OpenGL ***
-- Found X11: /usr/lib64/libX11.so
-- WARNING: *** KDE4 not found, just the style will be built ***
-- Found Qt-Version 4.8.4 (using /usr/bin/qmake-qt4)
-- Found X11: /usr/lib64/libX11.so
-- Found X11: /usr/lib64/libX11.so
-- Found Qt4: /usr/bin/qmake-qt4 (found suitable version "4.8.4", minimum required is "4.3.0") 
-- INFO: XRender was found - kwin deco & FX via GPU available!
CMake Error at blib/CMakeLists.txt:45 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  "QtBespin".
En googlelant un peu je trouve qu'il faut mettre la variable d'environement suivante :
export Automoc4_DIR=/usr/lib/automoc4
La recompilation se passe ensuite sans problème.
Je dois avouer que je suis content d'avoir trouvé cette solution car bespin est important pour moi et galérer pour ce genre de choses est pas très passionnant.
Ensuite pour le 2eme package ntrack je tombe sur ce message :
 
- qt (compilation depuis AUR)
==> Lancer la compilation de ntrack ? [O/n]
==> ---------------------------------------
==> 
==> Construction et installation du paquet
==> Installation/compilation des dépendances manquantes pour ntrack:
:: Il y a 13 membres dans le groupe qt
:: Dépôt extra
   1) qt5-base  2) qt5-declarative  3) qt5-graphicaleffects  4) qt5-imageformats  5) qt5-jsbackend
   6) qt5-multimedia  7) qt5-quick1  8) qt5-script  9) qt5-svg  10) qt5-tools  11) qt5-translations
   12) qt5-webkit  13) qt5-xmlpatterns

Là j'abandonne car je ne me rappelle même plus pourquoi je l'avais installé.

Il en reste que les AUR de arch sont très pratique mais n'est pas gentoo qui veut et gérer des packages sources necessitent pas mal de coordination.
Autant les problèmes de compil gentoo sont pénibles autant ils restent logiques, dépendances, USE flag, compatibilités de versions (stable/unstable), autant les AUR manquent de logiques même si ça doit finalement fonctionner en cherchant un peu.
Il en reste que Arch est surement la distro la plus à jour en terme de release, une vrai rolling avec une communauté fournie mais toujours un peu expérimentale.
Bon pour le desktop des curieux de linux.

lundi, février 25 2013

Owncould - Mot de passe admin perdu

Si comme moi vous avez trop de mot de passe pour trop d'application et il vous arrive de vous arracher les cheveux à retrouver vos mots de passe d'application Web voici une méthode bien pratique pour récupérer ceux de Owncloud.
Il y a déjà bien longtemps, les mots de passe étaient codé via un algorythme de cryptage type md5 ou sha1, mais les regles de sécurité allant en se durcissant, on utilise générallement un "salt" qui est une chaine de caractère ajoutée au mot de passe avant cryptage pour éviter de retrouver les mot de passe à partir des encodages de ces mot de passe (type rainbow table).
Il s'avere donc extremement difficile de retrouve le mot de passe en comparant les encodage d'autant plus que l'on ne connais pas le "salt".
De plus owncloud ne semble pas proposer par défaut de récupération du mot de passe par mail, c'est compliqué de retrouver celui ci lorsqu'il est oublié mais j'ai trouvé une solution simple à mettre en place.
Il suffit d'utiliser les fonctions owncloud de gestion de mot de passe via une page php, cela se fait en créant une script contenant :
?php
require_once('lib/base.php');
OC_User::setPassword('nimda', 'K1ll3rP4ssw0RD');
?
** Ajouter les < > en début fin de code.
Les arguments de la methode setPassword sont le login et le mot de passe.
Il faut creer le script par exemple saveme.php + chmod qui va bien et l'executer via un navigateur.
Le tour est joué mais par contre effacer le fichier ensuite ou bien en tout cas effacer les login/passwd et modifier les droits (000).

Il faut bien évidement avoir accès en ecriture à l'installation owncloud.

- page 2 de 6 -