systemx

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

jeudi, novembre 13 2014

Solydxk - Cure de jouvance


J'aime bien la distro solydxk qui propose une excellent intégration KDE sous ses air de Debian.
Une vraie debian sans se prendre la tête à tout assembler c'est quand même cool surtout pour installer KDE.
Voilà un an que ca tourne bien avec parfois de grosses mises à jour mais pas de probleme pour le moment.
Cependant je trouve le boot un peu longuet et en me penchant sur ce qui est démarré, horreur plein de trucs inutiles (pour moi !).
Les must (be removed)
# Support binaires (surtout windows)
apt-get purge binfmt-support  
# Machin truc upnp
apt-get purge minidlna minissdpd
# Pour guest vbox (mon pc n est pas un guest) 
apt-get purge virtualbox-guest-utils
# Un "uncomplicated" firewall au quel j ai jamais rien compris 
# Je repasserai sur un vrai iptables plus tard 
apt-get purge ufw
# hal/avahi vieux clou et sane utils pas utile (pour camera et autres devices)
apt-get purge hal avahi-daemon  sane-utils 
# Samba Samba ... je danse pas avec les fenêtres moi.
apt-get purge samba
# applications à l'utilité douteuse .. gps usb et convertisseur midi.
apt-get purge gpsd timidity

Puis ensuite je devalide les services :
bumblebeed bluetooth cpus*

Reste à voir pour les différents utilitaires dont l'utilité reste à prouver :
fancontrol cpufrequtils hddtemp hdparm lm-sensors loadcpufreq

Je suis toujours étonné de ne pas avoir de gestionnaire de service correct et bien pensé sous debian.
rcconf est graphique, chkconfig plutot redhat, update-rc.d pas pratique (ne permet pas de lister les demarrages).


M'enfin tout ca va disparaitre pour le sac de spaghetti systemd.

lundi, mai 26 2014

Fedora en japonais ... ca marche !


Après tant de deception, je me réussi à ecrire en japonais sous Fedora/KDE.

Quel casse tête et que de mauvaises indications car en effet elles stipulent aller dans le menu ... blabla qui est un menu gnome que je n'utilise pas ...

Une installation standard de ibus/ibus-anthy ne fonctionne pas correctement.

Après maintes recherches j'ai trouvé que le package uim-qt semble résoudre le probleme.

Il faut donc faire un yum install uim-qt puis sortir/entrer dans KDE avec un .xprofile tel que :
export GTK_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
export QT_IM_MODULE=ibus
ibus-daemon -d -x

Ensuite ca fonctionne même si les icônes ne s'affichent pas :
im.out.png
J'utilise Korora mais c'est vraiment que du Fedora et j'apprécie beaucoup l'intégration KDE/gtk/firefox qui est nickel.
Le Japonais était indispensable et c'est fait.
Comme package j'ai en plus de fonts japonaises :
ibus-anthy-1.5.5-3.fc20.x86_64
uim-anthy-1.8.6-3.fc20.x86_64
anthy-devel-9100h-24.fc20.x86_64
ibus-anthy-python-1.5.5-3.fc20.noarch
anthy-9100h-24.fc20.x86_64
scim-anthy-1.2.7-11.fc20.x86_64
uim-qt-1.8.6-3.fc20.x86_64
uim-1.8.6-3.fc20.x86_64
uim-anthy-1.8.6-3.fc20.x86_64
A noter l’étrange fonctionnement de group install et la mediocritude de yum mais je vois quand même :
[23:01] pierre@korora ~ $ yum langlist 
Loaded plugins: etckeeper, langpacks, refresh-packagekit, refresh-updatesd, versionlock
Installed languages:
        Japanese

mercredi, février 12 2014

Mageia 4 - Ca roule


Suite à la très douloureuse upgrade Korora/Fedora, je me lance dans une autre distrib à base de RPM.
Je me lance dans l'upgrade de la très bonne mageia qui depuis pas mal de mois que je la visite régulièrement est toujours aussi stable et de qualité.
Le wiki est simple et concis à en douter.
Je fais bien attention de lancer tout ca en console avec un screen au cas où mais 3 heures après le début de la manip j'avais un système mise à jour fonctionnel sans rien à retoucher.

Le seul bémol a été un repo trop lent, j'ai changé de repo en cherchant de la liste officielle et ca a été beaucoup mieux.

Dernière surprise au login, un écran d’accueil apparait pour présenter l'OS.


mageia4-1.png
Un peu d'accueil pour le gentil utilisateur, pourquoi pas.
Rien à redire ca tourne bien.

mercredi, janvier 22 2014

Connection SSH X11 et virtualbox affichage illisible


Je suis un grand utilisateur de vagrant mais parfois ca plante.
C'est plutôt virtualbox qui est capricieux mais dans ce cas le GUI est parfois indispensable.
Profitons de l'interface X11 et de son affichage déporté via SSH.

Sous CentOS il faut ajouter le package d'authentification X qui n'est en général pas installé sur un serveur.
yum install xorg-x11-xauth

Ensuite ajouter ces packages :
yum install urw-fonts libXfont
Sans ce package on aura un horrible affichage avec des carrés à la place des fontes :

vboxfontbroken.png Puis on se connecte (sur le port 999 au lieu de 22) en faisant passer les connection X11 (graphique) via ssh :
korora:/data/home/$ ssh -p 999 -X root@myhost.ovh.com
Last login: Wed Jan 22 22:23:27 2014 from yo.fbx.proxad.net
CentOS release 6.5 (Final)
Linux myhost.ovh.net 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

# echo $DISPLAY 
localhost:10.0
# VirtualBox
Et si votre Virtualbox est illisible avec plein de gros carré à la place des lettres :
yum install fontforge
On peut même simplifier avec le ssh_config :
toto : cat ~/.ssh/config 
Host lab
    HostName myhost.ovh.com    
    Port 999
    User root
    IdentityFile ~/.ssh/id_rsa_lab
    ForwardX11 yes
puis :
ssh lab

samedi, janvier 11 2014

Korora (fedora) upgrade report


Ca y est la version 20 est sortie sur Korora, la fille de Fedora, Je fais la procédure d'upgrade telle que décrite
root@korora ~ # fedup-cli --network 20 --debuglog /root/fedupdebug.log
..
virtualbox/20/x86_64/primary                                                           | 3.4 kB  00:00:00     
No upgrade available for the following repos: fedora-chromium-stable
getting boot images...
.treeinfo.signed  
... 
Downloading failed: could not verify GPG signature: No public key


Pour les problemes GPG j'essaye de trouver les clés sur le web.
Heuresement avec Fedora y a de l'info, et je recupérer la clé GPG :
rpmkeys --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-primary
Pour limiter les problemes de repo externes, j'enleve le enable de la plupart des repos non natif fedora.
Je passe enabled=0 dans /etc/yum.repos.d/fedora-chromium-stable.repo, pareil pour garminplugin.repo et virtualbox.repo (virtualbox n'est pas inclus dans fefora).

Je réessaye ca déboule :
root@korora ~ # fedup-cli --network 20 --debuglog /root/fedupdebug.log 
setting up repos...
getting boot images...
.treeinfo.signed                                                                       | 2.0 kB  00:00:00     
....
(2260/2260): xulrunner-26.0-2.fc20.x86_64.rpm                                          |  23 MB  00:00:43     
Importing GPG key 0xAE688223:
 Userid     : "RPM Fusion free repository for Fedora (20) "
 Fingerprint: 0017 ddfe fd13 2929 9d55 b1d3 963a 8848 ae68 8223
 Package    : rpmfusion-free-release-19-1.noarch (installed)
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-20

Downloading failed: The GPG keys listed for the "Korora 20 - x86_64" repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.
Failing package is: virtualbox-release-1.0-2.fc20.noarch
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-korora-19-primary
Je retombe sur les problèmes GPG pour la plupart des packages, au final pour arrêter la prise de tête j’enlève le package (comme suggéré dans les forums) :
root@korora ~ #  fedup-cli --network 20 --nogpgcheck
setting up repos...
...
[=======================================================================================]
WARNING: potential problems with upgrade
  iguanaIR-firmware-1.0.3-2.fc19.noarch (no replacement) requires iguanaIR-1.0.3-2.fc19.x86_64 (replaced by iguanaIR-1.0.5-2.fc20.x86_64)
verify local files 100% [====================================================================================]
...
rpm install 100% [===========================================================================================]
setting up system for upgrade
Finished. Reboot to start upgrade.
Packages without updates:
  GarminPlugin-0.3.22-1.1.x86_64
  a52dec-0.7.4-18.fc19.x86_64
  akmods-0.5.1-3.fc19.noarch
  bouncycastle-tsp-1.46-6.fc19.noarch
  btparser-0.26-1.fc19.x86_64
  ...
  vo-amrwbenc-0.1.2-1.fc19.x86_64
  webrtc-0.1-0.11.20130531svn3704.fc19.x86_64
  xorg-x11-drv-modesetting-0.8.0-3.fc19.x86_64
  1:firstboot-19.2-1.fc19.x86_64
  1:jockey-akmods-0.9.7-7.fc19.2.noarch
  1:jockey-selinux-0.9.7-7.fc19.2.noarch
  1:v8-3.17.6.14-2.fc19.x86_64
  1:vagrant-1.2.3-1.x86_64

WARNING: problems were encountered during transaction test:
  broken dependencies
    iguanaIR-firmware-1.0.3-2.fc19.noarch requires iguanaIR-1.0.3-2.fc19.x86_64
Continue with the upgrade at your own risk.

Comme on peut le voir dans le log plus haut, il faut rebooter pour uprader (je passe les commentaires ...)
Ce que je fais, au boot, il faut choisir fedup (donc si en multiboot on a pas pensé à faire un grub2-install rien ne se passe).
Mais au reboot ca semble se lancer mais rien du tout, je suis toujours en F19.
Je cherche et je trouve quelques joyeusetés dont celle qui semble correspondre à mon problème, avec un /var séparé de root ca marche pas. Ce qui est très pénible car je n'ai pas trop de place dans / et il download tout pour installer (il a besoin de 7 ou 8 Gb alors que mon / fait 8Gb utile /15Gb total).
Un peu galère de gérer tout ca mais au final j'arrive à faire l'espace nécessaire en déplacant de bouts de /usr.
Au reboot suivant, fedup puis c'est très long très très long (2 heures) en mode console (ordi inutilisable).
Mais cette fois ca fonctionne ! Ouf !

Mais les jouyeusetés continuent !
  1. Xorg crashe
  2. Au reboot plantage lamentable de l'inteface graphique, je regarde /var/log/Xorg.0.log ou je vois un probleme de driver nouveau.
    Je précise que c'est une upgrade et ca fonctionnait avant ....
  3. KDM devient skyzo
  4. Il a en double à la mise à jour : ---> Package kde-settings-kdm.noarch 0:19-23.fc19 will be updated ---> Package kde-settings-kdm.noarch 0:20-12.fc20.1 will be an update Evidement ca aide pas, je retire tout et reinstall le fc20.
    Je reboot (pas possible de faire un systemctl restart kdm.service ... ah systemctl !) et kdm se lance bien.
  5. Chromium est pas dispo
  6. J'avais enlevé la bête du à des erreurs de yum mais la reinstalle est impossible car le repo fedora/chromium n'est pas encore mis à jour (1 mois après la sortie du produit), il suffit de reprendre la version fc19.
    yum --releasever=19 install chromium

Quelle aventure et que de temps perdu, décidement les rolling release deviennent vraiment indispensable.
Quelles galère ces upgrades fedora ...
J'aurai pu réinstaller de 0 puis utiliser les scripts puppet ou salt mais bon c'est pas très élégant.
Une fois de plus fedora prouve qu'elle n'a rien d'une distro user friendly et korora a encore du chemin à parcourir pour pallier à cela.
C'est à mon avis ce qui pourrait vraiment faire la plus value de cette distro qui pour le moment n'est qu'une fedora avec des repos en plus ...

mercredi, décembre 11 2013

Android sous linux


J'ai recu un téléphone android au boulot.
J'avais déjà testé des iphone sous linux et pu les utiliser sans problème mais aussi bizarre que ca puisse paraitre, android est moins facile à utiliser sous linux que Ios qui permet de monter facilement un device en périphérique USB.
C'est d'ailleurs fort pratique et le choix de google de passer par un protocole propriétaire MTP est des plus ennuyeux.
J'avais lu attentivement la page de linuxfr qui date un peu sur le sujet et était très pessimiste quand à l'utilisabilité de la chose.

Heureusement je suis sous KDE et j'ai finalement découvert que il suffit d'utiliser un ajouter le paquer kio-mtp pour avoir accès simplement au téléphone MAIS uniquement via Dolphin (le gestionnaire de fichier KDE).
La preview des images ne semble pas fonctionner et la vitesse pas top (ca depends un peu des distros/versions) mais c'est utilisable.


dolphin-mtp2.png

jeudi, juillet 18 2013

Korora - X ecran noir - Le fix en chroot

J'avais du faire une mise à jour Korora recement avant d'arreter l'ordi et aujourd'hui au démarrage au lancement de X, ecran noir.
Rien du tout, même pas de Ctr+Alt+Fx
Je reboot sur Sabayon, cherche sur le web et trouve une piste.
Je monte la Korora en chroot (via blk).
[22:17] root@sabayon / # yum downgrade xorg-x11-server-Xorg
Modules complémentaires chargés : etckeeper, langpacks, refresh-packagekit, refresh-updatesd,
...
rpmfusion-nonfree-updates                                                 | 3.3 kB  00:00:00     
...
updates/19/x86_64/group_gz                                                | 384 kB  00:00:00     
Résolution des dépendances
--> Lancement de la transaction de test
---> Le paquet xorg-x11-server-Xorg.x86_64 0:1.14.1-4.fc19 sera une rétrogradation
---> Le paquet xorg-x11-server-Xorg.x86_64 0:1.14.2-3.fc19 sera effacé
--> Résolution des dépendances terminée

Dépendances résolues

=================================================================================================
 Package                        Architecture     Version                  Dépôt            Taille
=================================================================================================
Retour à la version précédente :
 xorg-x11-server-Xorg           x86_64           1.14.1-4.fc19            fedora           1.3 M

Résumé de la transaction
=================================================================================================
Retour à la version précédente  1 Paquet

Taille totale des téléchargements : 1.3 M
Is this ok [y/d/N]: y
Downloading packages:
xorg-x11-server-Xorg-1.14.1-4.fc19.x86_64.rpm                             | 1.3 MB  00:00:01     
...
  Installation : xorg-x11-server-Xorg-1.14.1-4.fc19.x86_64                                   1/2 
  Nettoyage    : xorg-x11-server-Xorg-1.14.2-3.fc19.x86_64                                   2/2 
...
  Vérification : xorg-x11-server-Xorg-1.14.1-4.fc19.x86_64                                   1/2 
  Vérification : xorg-x11-server-Xorg-1.14.2-3.fc19.x86_64                                   2/2 
...
Supprimé :
  xorg-x11-server-Xorg.x86_64 0:1.14.2-3.fc19                                                    
Installé :
  xorg-x11-server-Xorg.x86_64 0:1.14.1-4.fc19                                                    
Reboot et tout va bien.
Ensuite pour éviter les catastrophes on peut locker des versions de package mais ... il faut ajouter un autre package.
Pour masquer/empecher une version de package il faut avoir le package yum-plugin-versionlock.noarch.
Ensuite :
[22:28] root@korora ~ # yum versionlock xorg-x11-server-Xorg 
Loaded plugins: etckeeper, langpacks, refresh-packagekit, refresh-updatesd, versionlock
Adding versionlock on: 0:xorg-x11-server-Xorg-1.14.1-4.fc19
versionlock added: 1
[22:29] root@korora ~ # more /etc/yum/pluginconf.d/versionlock.list
# Added locks on Thu Jul 18 22:29:35 2013
0:xorg-x11-server-Xorg-1.14.1-4.fc19.*
Il y a un embryon de man : man yum-versionlock
Il en reste que tout ca est assez (très ...) mal documenté et un peu brouillon.
De la fedora quoi !

PS : Le post qui m'a permis de resoudre ce probleme.

mardi, juillet 9 2013

ruby et rvm comment gérer les versions de ruby (avec vagrant et veewee)


En essayant d'installer veewee sur différentes machines, je suis tombé sur divers problemes de compatibilité de librairies ruby.
En lisant différentes docs, j'ai été séduit par l'utilitaire rvm qui permet de créer des environnement cloisonnés ruby.
J'ai décidé dans le cadre d'une install multiboot de créer un répertoire contenant ruby + vagrant + veewee et de gérer les versions manuellement, le tout dans un répertoire défini /data/apps/rvm.
Le but de la manip est d'installer des applications ruby et de partager ces installations entre les différents OS installés sur la machine en s'affranchissant des dépendances de package et de pouvoir gérer les gems manuellement.
Tout d'abord avant les opérations j'ai un ruby là :
[pierre@fedora pierre]$ which ruby 
/usr/bin/ruby
Je suis donc le tuto d'installation en veillant bien chaques étapes :
curl -L https://get.rvm.io > rvminstall

Editer rvminstall et changer avec /data/apps/rvm (qui est le repertoire d'installation partagé entre les différents OS) où il y a "rvm_prefix=".
Si on est derrière un proxy, modifier /etc/visudo :
Defaults env_keep +="http_proxy"
Defaults env_keep +="https_proxy"
Puis comme spécifié dans la doc utiliser sudo pour ne rien créer dans la home user ou root.
Afin d'etre complétement indépendant du système j'installe tout en local (dont ruby en derniere version) :
$ export rvm_path=/data/apps/rvm 
$ sudo ./rvminstall version latest --ruby
$ rvm list rubies
rvm rubies
=* ruby-2.0.0-p247 [ x86_64 ]
# => - current
# =* - current && default
#  * - default
Ensuite on crée l'enveloppe pour vagrant :
[pierre@fedora apps]$ rvm gemset create vagrant
gemset created vagrant  => /data/apps//rvm/gems/ruby-2.0.0-p247@vagrant
Et on installe :
root@fedora apps # gem install vagrant
Fetching: archive-tar-minitar-0.5.2.gem (100%)
Successfully installed archive-tar-minitar-0.5.2
Fetching: ffi-1.9.0.gem (100%)
OOPS problème :
root@fedora apps # gem install veewee 
ERROR:  While executing gem ... (Gem::DependencyError)
    Unable to resolve dependencies: fog requires net-scp (~> 1.1)
On corrige :
root@fedora apps # gem install net-scp
Fetching: net-ssh-2.6.7.gem (100%)
Successfully installed net-ssh-2.6.7
..
2 gems installed

root@fedora apps # gem install fog -v 1.8
Building native extensions.  This could take a while...
Successfully installed nokogiri-1.5.10
Fetching: ruby-hmac-0.4.0.gem (100%)
..
3 gems installed
root@fedora apps #  gem install veewee
Fetching: Platform-0.4.0.gem (100%)
Successfully installed Platform-0.4.0
...
22 gems installed
Pour finir j'install le plugin salt pour vagrant.
root@fedora apps # gem install vagrant-salt
Fetching: vagrant-salt-0.4.0.gem (100%)
...
Installing ri documentation for vagrant-salt-0.4.0

A noter que la création de rvm à créé les fichiers /etc/bash.bashrc et /etc/profile.d/rvm.sh
Je les enlève et créé un environement dans mon .bashrc :
export rvm_bin_path=/data/apps/rvm/bin
export rvm_path=/data/apps/rvm
export rvm_prefix=/data/apps
export rvm_script_path=/data/apps/rvm
. $rvm_script_path/scripts/rvm
Ensuite on peut y aller (lancer un nouveau bash) :
$ which vagrant 
/data/apps/rvm/gems/ruby-2.0.0-p247/bin/vagrant
$ which veewee 
/data/apps/rvm/gems/ruby-2.0.0-p247/bin/veewee

Sous gentoo j'ai ces erreurs :
@gentoox64 /data/apps/rvm $ gem install veewee
Error loading RubyGems plugin "/data/apps/rvm/gems/ruby-2.0.0-p247@global/gems/rubygems-bundler-1.2.1/lib/rubygems_plugin.rb": libcrypto.so.10: cannot open shared object file: No such file or directory - /data/apps/rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/x86_64-linux/openssl.so (LoadError)
J'ai patché /usr/lib64 en faisant des liens
ln -s /usr/lib64/libssl.so.1.0.0  /usr/lib64/libssl.so.10
ln -s /usr/lib64/libcrypto.so.1.0.0 /usr/lib64/libcrypto.so.1.0

lundi, juillet 8 2013

vagrant veewee


Vagrant est un outil sympa pour se créer des VM à la volée, en quelque sorte se faire un mini cloud.
J'utilise virtualbox mais cela fonctionne sous kvm et même VMware quelquechose. Il y a une bonne page de présentation sur ce blog. Cependant il y a deux inconvenients majeurs.
  1. vagrant home
  2. Par default vagrant créé tout dans la home directory ce qui rends cette home extremement volumineuse et ne devrait pas être inclus dans les backups de la home.
    Pour résoudre le probleme, il faut (à partir de la version 1.1.x je crois) utiliser :
    export VAGRANT_HOME=/data/virt/Vagrant/
    La doc parle aussi de VAGRANT_CWD dans le doute je met les 2.
  3. Les bases box
  4. Ce sont des machines pré profilées que l'on peut recupérer directement du WEB, mais on ne maitrise pas trop ce qu'il y a dedans.
    Créer une base box à partir des iso OS est un process un peu lourd (decrit ici). Afin de pallier à cet inconvenient l'utilitaire veewee permet d'automatiser ce processus et surtout fonctionne avec les standards d'installation serveur.
    On peut en effet lancer son kickstart comme pour toute installation de server, parfait pour les admins systemes (ou preseed pour les debian).
    Je vais donc créer avec veewee des modèle de VM qui seront ensuite importés et packagés par vagrant pour créer (deployer) des VM.

On initialise vagrant (pour l'installation utiliser la dernière version de l'auteur, les package OS étant souvent obsolètes (sauf gentoo testing)).
$ cd $VAGRANT_HOME
$ vagrant init 
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

Le fichier Vagrantfile décrit la ou les machines gérées par vagrant.
Parfait maintenant on peut commencer à travailler.
Pour les tests ci dessous, j'utilise une centos 6.4.
Je télécharge en prévision des installations l'iso source et le guest addition et les place dans le repertoire $VAGRANT_HOME/iso :
  • vboxaddition (en fonction de la version installée)
  • http://download.virtualbox.org/virtualbox/4.1.14/VBoxGuestAdditions_4.1.14.iso
  • centos
  • http://mirror.ovh.net/ftp.centos.org/6.4/isos/x86_64/CentOS-6.4-x86_64-minimal.iso
On créé l'enveloppe de notre nouvelle box :
vagrant basebox define centos64 CentOS-6.3-x86_64-minimal
Le template 6.4 n'existant pas je pars d'une version 6.3 qui sera downloadée d'internet.
Cela créé un repertoire dans definitions/centos64 très intéressant avec entre un ks.cfg bien connu des admin redhat.
Afin de passer en 6.4 je modifie le fichier definition.rb :
  :os_type_id => 'RedHat_64',
  :iso_file => "CentOS-6.4-x86_64-minimal.iso",
  :iso_src => "",
  :iso_md5 => "4a5fa01c81cc300f4729136e28ebe600",
On retrouve le fichier que j'ai downloadé précédemment (et son md5sum).
Ensuite après avoir adapté les scripts je change cette partie :
:postinstall_files => [
      "top.sh"
  ],
Le fichier sera copié sur le nouveau modèle et executé au moment de la création.
Puis je modifie les fichiers de config qui sont en 2 type :
  1. ks.cfg
  2. Ajout de clavier francais, partitionnement ...
  3. top.sh
  4. il contient en gros les opérations d'installation du modèle (voir le lien de création manuelle de modèle vagrant).
    Ainsi que l'installation des salt-minion (à la place de puppet) pour permettre le provionning au boot à la création de la VM.
On lance la creation de la box :
% veewee vbox build centos64 --debug --redirectconsole
Creating vm centos64 : 480M - 1 CPU - RedHat_64
Creating new harddrive of size 10140, format vdi, variant Standard 
Attaching disk: /data/virt/centos64/centos64.vdi
Mounting cdrom: /data/virt/Vagrant/iso/CentOS-6.4-x86_64-minimal.iso
Mounting guest additions: /data/virt/Vagrant/iso/VBoxGuestAdditions_4.2.14.iso
Received port hint - 7222
Found port 7222 available
Received port hint - 7222
Found port 7222 available
Changing ssh port from 22 to 7222
Waiting 10 seconds for the machine to boot
Received port hint - 7122
Found port 7122 available

C'est assez sympa de voir la vbox créée de zéro et surtout le kickstart est vraiment cool.
On peut le voir sur le screenshot ci dessous où veewee passe les paramètres de boot kickstart au moment du boot de l'iso : veewee-vbox1.png
Veewee est même assez sympa pour créer un server web local qui va répondre à la demande de kickstart.
On suite aussi dans les logs veewee (en mode debug) :
Typing:[1]:  text ks=http://10.0.2.2:7122/ks.cfg
Done typing.
Une fois que cela est terminé, on valide la box :
veewee vbox validate 'centos64'
Je suis un peu dubitatif quand à l'utilité de cette étape car les vérifications sont pas forcement appropriées. Puis on exporte :
veewee vbox export 'centos64'   


Ensuite on peut utiliser cette box dans vagrant avec le provisionning type salt/puppet.
vagrant package --base centos64 
mv /data/virt/Vagrant/package.box /data/virt/Vagrant/centos64.box
On l'ajoute dans notre repository de box :
vagrant box add centOS-6.4 centos6.4.box
Cela va créer dans VAGRANT_HOME un repertoire boxes qui contient les infos pour utiliser ces box. Modifier le fichier Vagrantfile :
  config.vm.box = "centOS-6.4"
On démarre la machine :
pierre@gentoox64 /data/virt/Vagrant $ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'centOS-6.4'
...
On se loggue :
pierre@gentoox64 /data/virt/Vagrant $ vagrant ssh 
Welcome to your Vagrant-built virtual machine.
[vagrant@localhost ~]$ id 
uid=501(vagrant) gid=501(vagrant) groups=501(vagrant),10(wheel)
[vagrant@localhost ~]$ sudo su - 
[root@localhost ~]#
Pour que Salt soit accessible au provisionnement de virtualbox, il faut ajouter le plugin vagrant/salt qui s'installe très facilement avec l'option plugin de vagrant des dernières versions.
Ces solutions sont vraiments très bien pour créer des environements de tests et de les distribuer.
Il suffira ensuite de donner la box à une personne disponsant de vagrant et la création est un jeu d'enfant.
Par contre le gros point noir est l'installation des composants vagrant/veewee et ruby, très capricieux sur les versions et en général la version de Vagrant est périmée sur les distros (ubuntu par exemple).
De plus l'auteur de vagrant ne propose plus des gems mais des packages.
A notre que le package deb fonctionne sur debian/ubuntu. Ca simplifie pour vagrant mais ne resouds rien pour veewee.
La méthode rvm pour veewee est pour moi la seule qui fonctionne avec des packages de l'auteur (ou gentoo en testing).
Pour un utilisateur simple de box vagrant le package s'est révélé très efficace. PS : J'ai installé sans probleme avec le package de chez vagrant avec ensuite veewee en gem (en temps que user local) avec :
gem install net-scp  # Peut être pas nécessaire car inclus avec fog (à verifier)
gem install fog --version 1.8
gem install veewee
Mettre dans ~/.gemrc pour ne pas installer la partie doc :
install: --no-document
update: --no-document
gem: --no-ri --no-rdoc

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.

- page 1 de 5