systemx

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

jeudi, février 4 2016

Kubuntu - Unity light et u, dpkg et le ménage

1 - Unity light
J'utilise en général KDE mais parfois envie de changer et unity a de meilleures intégrations avec les vpn de network manager ce qui est utile au boulot.
Sur une Kubuntu, je veux installer Unity mais le meta paquet unity-desktop ramène les applis que je n'utilise pas.
J'install donc unity (pour ensuite enlever le gras) mais pas de menu dans sddm (qui utilise les fichier .desktop dans /u sr/share/xsessions).
Il faut de plus ajouter le paquet unit-session (qui entraine aussi gnome-session) pour voir le fichier unity.session.

2 - Le ménage
L'installation reste légère mais il faut ensuite faire le ménage dans les lens et les scope (dpkg -l unity*).
Entre autre unity-lens-shopping, unity-scope-gourmet, unity-asklibreoffice ...

3 - Le ménage du ménage. Le système de paquet laisse pas mal de résidus lorsque les packages sont enlevés.
Cependant les packages installés et enlevés sont gardés dans la base des packages.
On peut consulter cette base avec la commande dpkg :
K15 xsessions # dpkg -l unity*    
....
rc  unity                                          7.3.2+15.10.20151016-0ubuntu amd64                        Interface designed for efficiency of space and interaction.
ii  unity-asset-pool                               0.8.24+15.04.20141217-0ub il unt all                          Unity Assets Pool
un  unity-chromium-extension                                                                     (no description available)
On voit la première colonne avec des infos mystérieuses qui sont en fait des infos sur le status des packages tels que decrit dans le man (1) de dpkg-query.
Les lettres sont dans l'ordre Action/Status/Erreur
Donc
ii : à installer et installé
rc : Enlevé mais avec fichiers de config
un : inconnu et non installé (suite à un purge).

Pour enlever les restes des packages il faut donc faire un purge sur les paquer rc :
dpkg --purge $(dpkg -l | grep "^rc" | tr -s ' ' | cut -d ' ' -f 2)

mardi, décembre 22 2015

Archeries


Il y a pas à dire Arch est une très bonne distro, surtout avec une communauté active, une doc de qualité et une efficacité rare.
Cependant les mises à jour sont parfois très mystérieuses.
Celle de ce jour commence par les classiques tu veux remplacer toto/tutu par toto/tutu-toto ?
Le genre de truc incompréhensible et surtout on s'est fout un peu.
Exemple du jour :
:: Remplacer kdeadmin-ksystemlog par extra/ksystemlog ? [O/n] o
:: Remplacer kdegraphics-ksnapshot par extra/spectacle ? [O/n] o
:: Remplacer kdemultimedia-ffmpegthumbs par extra/ffmpegthumbs ? [O/n] o
On met oui parceque sinon on avance pas, de plus étant passé à plasma 5, je m'attends à ce genre de choses.
Mais ... surprise ca continue pour se terminer sur un magnifique :
:: libkolab et libkolab4 sont en conflit. Supprimer libkolab4 ? [o/N] o
erreur : la préparation de la transaction a échoué (la satisfaction des dépendances a échoué)
:: kdepim-wizards : requiert kdepim-kresources
Au final après différentes recherches, je passe à la methode forte :
[root@archx64 ~]# pacman -R kdepim-akonadiconsole kdepim-akregator kdepim-blogilo kdepim-console kdepim-kaddressbook kdepim-kalarm kdepim-kjots kdepim-kleopatra kdepim-kmail kdepim-knode kdepim-knotes kdepim-kontact kdepim-korganizer kdepim-kresources kdepim-ktimetracker kdepim-wizards
Ca passe mais quid de ces applications ... que je n'utilise guère et heuresement car l'installation de kmail entre en conflit entre libkdepim and kdepim-libkdepim, bien sûr, bien sûr.
Le passage manuel de KDE4 à plasma 5 est plutot une bonne chose (même si plasma4 est maintenant EOL) mais il faut maintenir derrière et la c'est très moyen.

samedi, décembre 12 2015

Opensuse - Tumbleweed ... vraiment ???


Toujours intrigué par le lézard et pour faire des tests Salt, me revoila parti dans une installation multiboot sur mon PC.
Le boot de l'iso me fait un peu peur ecran noir et autre mais au final ca boot et l'install se passe bien.
J'aime toujours autant le choix d'avoir plein de choix dans l'installation, le choix par défaut du partitionnement est par contre complétement stupide.
Il propose de reformatter ma partition Sabayon pour l'OS et mon /data pour un /home.
Juste l'habituel probleme de grub2-mount qui boucle à la création de grub mais je ne rejette pas la faute sur cet OS bien que le phénomène soit très prononcé (obligé de faire un pkill en boucle de grub2-mount).
Hum, vaut mieux pas être débutant, à part ca tout se passe bien, le reboot faire une sorte de seconde étape d'install ou je comprends pas trop ce qu'il faut faire puis le reboot final.
Jusque la que du classique, au reboot, première signe, le clavier de sddm est en anglais alors que l'install se fait bien en clavier francais.
J'arrive à me logguer avec mon login habituel mais mon environement de travail est à la mode suse, tout mes settings sont ignorés.
Bon bon, une mise à jour post install est d'usage, reboot, puis impossible de me connecter depuis sddm, je me retrouve mmédiatement sur la mire de login ...
Bref encore du debug pénible ou bien jeter l'éponge.
Pour une distro de cette envergure, on s attends à ce que tout marche bien pour les choses de base, mais non, vraiment, non.

jeudi, octobre 15 2015

Salt - Impossible d'installer des packages Key Error

Après avoir installé une toute fraiche Korora, je lance ma post installation via Salt et malheur impossible d'installer un package.
Salt me vomis un message très moche :
File "/usr/lib/python2.7/site-packages/salt/utils/lazy.py", line 90, in __getitem__ raise KeyError(key) KeyError: 'pkg.installed'

Evidement je lance en debug, isole des state mais rien n'y fais.
Tout ce qui a trait au pkg.xxx plante avec cette même erreur.
Le même higstate fonctionne sur la même machine sur une Fedora 22 ...
Qu'y a-t-il de différent, le grain os donne Kokora :
21:50 root@Korora ~ # salt-call --local grains.get os local:
Korora
Est ce que cela pourrait venir de la ...
Je change le fichier /etc/os-release et confirme le changement de grain :
21:53 root@Korora ~ # sed -i s/Korora/Fedora/ /etc/os-release
21:53 root@Korora ~ # salt-call --local grains.get os local:
Fedora
Et la miracle le highstate passe sans problème !

mercredi, janvier 7 2015

OpenSuse nouvel essai


Enfin une distro rpm en rolling release !
Je suis toujours resté dubbitatif sur openSuse, j'ai d'hors et déjà tenté d'utilisé Tumbleweed mais ca s est terminé en catastrophe (et fin de mon utilisation de openSuse).
Mais cette nouvelle version qui semble une vraie tentative de passer en RR pour cette distro.
J'ai suivi cette page pour l'installation.
L'install de Factory se passe bien, une grosse update après la prémière installation, un coup de Salt pour post configurer la bete et tout fonctionne.
Je suis particulièrement content de pouvoir enlever des packages dont les dépendances sont trop fortes sur maintes distro.
Donc c'est partis une install à partir de l'image du jour, ca se passe bien.

Quelques updates plus tard, je m'apercois que les packages savement enlevés se font rajouter comme dépendances, toujours pas de support multimedia correct et enfin aprés 2 ou 3 mises à jour ca commence à partir en sucette.

Je suis pourtant pas un débutant mais, j'ai pas du bien suivre les explication entre le thumbleweed et le factory.
Que tout ca est compliqué, pour un pietre résultat, décidement Suse et moi on est pas des amis.

Je retourne sur ma Sabayon chérie qui tourne depuis presque 5 ans et sans aucun probleme de mise à jour depuis quelques années, ou mon Arch plus branchouille qui nécessite plus d'attention mais qui fonctionne quand même bien.

Je sais pas si j'aurai le courage (et le temps) de retenter l'aventure suse en rolling release, pourtant une distro rpm en rolling ca le ferait bien.

samedi, janvier 3 2015

Upgrade Arch qui ne fonctionne pas.


Pour la nouvelle année un plantage de l'upgrade Arch :
[root@archx64 ~]# pacman -Syu 
:: Synchronisation des bases de données de paquets...
 core                                     121,6 KiB   617K/s 00:00 [#####################################] 100%
 extra                                   1809,1 KiB  1295K/s 00:01 [#####################################] 100%
 community                                  2,4 MiB  1359K/s 00:02 [#####################################] 100%
:: Début de la mise à jour complète du système...
:: Remplacer mesa-dri par extra/mesa ? [O/n] o
avertissement : skrooge : ignore la mise à jour du paquet (1.9.0-1 => 1.10.0-2)
résolution des dépendances...
avertissement : cycle de dépendances détecté :
avertissement : harfbuzz sera installé avant sa dépendance freetype2
recherche des conflits entre paquets...
erreur : la préparation de la transaction a échoué (la satisfaction des dépendances a échoué)
:: package-query : requiert pacman<4.2
Je pensais à un simple conflit de dépendances mais le problème semble plus compliqué (voir la derniere ligne ... ).
Pacman ayant été upgradé récement on tombe dans un conflit avec des packages externes voir ce post.
La solution :
[root@archx64 etc]# pacman -R yaourt
[root@archx64 etc]# pacman -R package-query  
Puis l'upgrade standard fonctionne.

Pour conclure, pour qu'une distro linux fonctionne bien il faut vraiment éviter les repos externes.
Les AUR c'est pratique mais à long terme plutot casse gueule, tout ca ne me pousse pas à penser que Arch est LA distro.
En rolling release Sabayon est plus stable et l'offre de package quasi aussi riche (sans compter les AUR et l'accès à emerge dans Sabayon). Arch rapide, légère mais pas la plus efficace !

mercredi, décembre 17 2014

Systemd et bizarrerie system

Depuis quelques temps ma Solydxk qui est une debian sous systemd avait différents problèmes.
Le plus génant network manager ne fonctionnait pas bien et aussi parfois au boot en passant par plymouth (joli graphique qui cache les messages de boot) le système frisait.
Différentes petites choses qui génait vraiment le confort général.
Au boot je passait en mode texte, network_manager ne fonctionnait pas après le démarrage de KDE.
Il fallait le relancer manuellement après le login et son fonctionnement restait lent.

J'ai regardé mes fichiers de logs et trouvé le message suivant (cf forum solydkx) :
Dec 13 15:44:46 solydxk-x64 systemd[1]: Failed to start RealtimeKit Scheduling Policy Service. Dec 13 15:44:46 solydxk-x64 systemd[1]: Unit rtkit-daemon.service entered failed state. Dec 13 15:45:11 solydxk-x64 dbus[1555]: [system] Failed to activate service 'org.freedesktop.RealtimeKit1': timed out

En regardant divers forum je vois que ca semble lié à un /tmp qui est un lien sur /var/tmp. Je m'apercois avec surprise que c'est le cas sur ma distrib.
L'unti qui s'occupe de /tmp était down, quelques commande pour debugger :
Je fais les vérifications systemd qui me permette de voir que c'est quand même assez pratique :
  • systemctl --state=failed
  • Pour voir les services qui ne sont pas bien lancés.
  • systemctl list-unit-files
  • Pour voir chaque unit ( ~service) et son status. Dans mon cas tmp.mount
  • fichier correspondant à cette unit
  • /lib/systemd/system/tmp.mount qui explique les conditions de démarrage et paramètres à appliquer.
  • Voir le journal systemd d'un processus
  • journalctl -b _PID= C'est bien pratique de pouvoir avoir ce genre de raccourcis.


A noter que pour monter /tmp il n'y a pas besoin d'entrée dans la fstab sauf si on veut customiser le montage qui par défaut fait la moitié de la RAM.

Systemd est bien envahissant et moins pratique que les bons vieux scripts d'init.
A force de l'utiliser ça deviendra naturel mais aussi de plus en plus envahissant !

A noter que rtkit est utilisé uniquement par pulseaudio ... du même auteur que systemd !

PS : Depuis ce poste Pottering a pas mal documenté : Partie 1 et partie 2.

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.

vendredi, juin 27 2014

System performance avec sar

Memo des commandes sar pour observer les perfs d'un systeme. La première option chiffrée de sar est l'interval, une deuxième option permet de déterminer le nombre d'itération. Sans cette deuxième option, ca boucle indéfiniment (Ctrl C pour quitter).
  • load average
  • Montre la moyenne des process dans la run queue sur 1/5 et 15' . 1 pour une CPU c'est 100% de plein.
    root@lab # sar -q 1 
    
    05:21:26      runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15
    05:21:27            2       639      0,78      0,41      0,39
    05:21:28            1       639      0,78      0,41      0,39
    05:21:29            0       639      0,78      0,41      0,39
  • Usage de CPU
  • On y retrouve le temps passé dans le kernel (système), temps utilisateur et aussi l'interessant steal qui est du temps passé en attente du à un hyperviseur qui sert une autre machine. Le iowait est aussi interssant car il montre le temps passé en attente d'entrée/sortie.
    root@lab # sar -u 1 -P ALL
    Linux 2.6.32-431.el6.x86_64 (ns2356435.ovh.net)         27/06/2014      _x86_64_        (12 CPU)
    
    05:28:58        CPU     %user     %nice   %system   %iowait    %steal     %idle
    05:28:59        all      0,50      0,00      5,80      0,00      0,00     93,70
    05:28:59          0      0,00      0,00      5,15      0,00      0,00     94,85
    05:28:59          1      0,00      0,00      1,01      0,00      0,00     98,99
    05:28:59          2      1,01      0,00      4,04      0,00      0,00     94,95
    05:28:59          3      0,00      0,00     13,13      0,00      0,00     86,87
    05:28:59          4      0,99      0,00      0,99      0,00      0,00     98,02
    05:28:59          5      0,99      0,00      0,00      0,00      0,00     99,01
    05:28:59          6      0,00      0,00      2,02      0,00      0,00     97,98
    
  • disques
  • On peut voir une vue d'ensemble de l'utilisation disque
    Server # sar -b 5 
    Linux 2.6.32-431.5.1.el6.x86_64 (bgsc409139)    07/02/14        _x86_64_        (24 CPU)
    
    12:07:40          tps      rtps      wtps   bread/s   bwrtn/s
    12:07:45       417.21    132.39    284.82   6970.04   3170.85
    12:07:50       363.54    120.57    242.97   7051.73   2727.49
    12:07:55       455.60    134.83    320.77   6556.42   3542.16
    
    Il faut regarder le champs tps : transaction par secondes. Un disque SATA standard à peu près 50tps. un SSD monte beaucoup plus haut.
    Pour plus de detail on peut regarder les statistiques par disque :
    root # sar -d -p 5 
    Linux 2.6.32-431.el6.x86_64 (ns2356435.ovh.net)         02/07/2014      _x86_64_        (12 CPU)
    
    05:21:47          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
    05:21:52          sdc      1,00      0,00      5,20      5,20      0,01      7,60      7,60      0,76
    05:21:52          sdb      1,80      0,00     14,40      8,00      0,00      0,00      0,00      0,00
    05:21:52          sdd      1,00      0,00      5,20      5,20      0,01      7,20      7,20      0,72
    05:21:52          sda      1,80      0,00     14,40      8,00      0,00      0,11      0,11      0,02
    05:21:52          md1      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00
    05:21:52          md3      1,20      0,00      9,60      8,00      0,00      0,00      0,00      0,00
    05:21:52        md127      0,60      0,00      4,80      8,00      0,00      0,00      0,00      0,00

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 ...

- page 1 de 6