systemx

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

jeudi, février 4 2016

Kubuntu - Unity light, 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)

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

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

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.

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.

vendredi, avril 5 2013

Comment Sauvegarder/restaurer/deplacer ses distro/partitions linux

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

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


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

vendredi, mars 15 2013

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

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

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

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

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

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

mercredi, juin 13 2012

Créer un certificat auto signé en script

Le but de la manip est de générer des certificats autosignés par script (incluant un CSR).
La manip standard se décompose en 3 étapes :
  1. Génération de la clé privée
  2. Génération du CSR avec la clé privée
  3. Le CSR peut aussi être utilisé pour acheter un certificat chez un fournisseur.
  4. Génération du certificat
On commence le script par les variables :
CERTDIR=/etc/apache/cert
CERTDOMAIN=mydomain.com
CERT_CONFIG_FILE=/tmp/certconfig

  1. clé privée
  2. openssl genrsa -out $CERTDIR/CERTDOMAIN.key 2048
    chmod 400 $CERTDIR/CERTDOMAIN.key
    
    2048 est le nombre de bits.
  3. CSR
  4. Pour générer le CSR il faut remplir un certain nombre de champs en interactif. Pour contourner l'interactivité il faut créer un fichier de propriété qui sera passé en paramètre de la demande du CSR.
    cat << fin > $CERT_CONFIG_FILE
    [ req ]
    default_bits = 2048
    encrypt_key = yes
    distinguished_name = req_distinguished_name
    prompt = no
    
    [ req_distinguished_name ]
    C=FR
    ST=France
    L=Paris
    O=MA SUPER BOITE
    OU=WEB DIVISION
    CN=$CERTDOMAIN
    emailAddress=root@localhost
    fin
    
    Puis générer le csr :
    openssl req -verbose  -config $CERT_CONFIG_FILE  -new -key $CERTDIR/$CERTDOMAIN.key -out $CERTDIR/$CERTDOMAIN.csr
    
  5. CERT
  6. Enfin le certificat :
    openssl x509  -days 9999 -req -in $CERTDIR/$CERTDOMAIN.csr  -signkey $CERTDIR/$CERTDOMAIN.key -out $CERTDIR/$CERTDOMAIN.cert
    

Pour utiliser ca dans apache il suffit de faire un vhost en SSL :
cat << fin >> /etc/httpd/vhosts.d/$CERTDOMAIN.conf
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile $CERTDIR/$CERTDOMAIN.cert
SSLCertificateKeyFile $CERTDIR/CERTDOMAIN.key
fin

lundi, juin 11 2012

Mise en veille/hibernation qui fonctionne sur ASUS

Un bon mémo pour configurer linux sur un portable ASUS pour se mettre en veille.
Ca fonctionne sous sabayon/gentoo et arch, probablement chez ubuntu/debian aussi. Tout d'abord ce qui bloque c'est l'extinction de certaines device, pour corriger le probleme, il font donc avant le suspend/hibernate dévalider les devices qui utilisent "ehci_hcd" et décharger le module xchi du noyau.
Le script va donc chercher les devices dans /sys/bus/pci/drivers/ehci_hcd/ (c'est en rapport avec l'USB) et utiliser les fichier bind et unbind pour les desactiver/activer.
Pratique le sysfs.
On le met dans /etc/pm/sleep.d et lien dans /etc/pm/power.d (lien, avec un nom type 20-stopdevices).
Le " egrep "^$HEX+:$HEX+:$HEX"`" récupère les ID des devices chargées dans le kernel (à la place de modules que l'on pourrait adresser avec modload ...) qui se trouvent dans /sys/bus/pci/drivers/ehci_hcd/ avec les fichiers bind/unbind pour effectuer les opérations.
En pratique on utilise ce script (recupéré ).
#!/bin/bash

DEV_LIST=/tmp/usb-dev-list
DRIVERS_DIR=/sys/bus/pci/drivers
DRIVERS="ehci xhci" # ehci_hcd, xhci_hcd
HEX="[[:xdigit:]]"
MAX_BIND_ATTEMPTS=2
BIND_WAIT=0.1

unbindDev() {
        echo -n > $DEV_LIST 2>/dev/null
      for driver in $DRIVERS; do
        DDIR=$DRIVERS_DIR/${driver}_hcd
        for dev in `ls $DDIR 2>/dev/null | egrep "^$HEX+:$HEX+:$HEX"`; do
          echo -n "$dev" > $DDIR/unbind
          echo "$driver $dev" >> $DEV_LIST
        done
      done
}

bindDev() {
      if [ -s $DEV_LIST ]; then
        while read driver dev; do
          DDIR=$DRIVERS_DIR/${driver}_hcd
          while [ $((MAX_BIND_ATTEMPTS)) -gt 0 ]; do
              echo -n "$dev" > $DDIR/bind
              if [ ! -L "$DDIR/$dev" ]; then
                sleep $BIND_WAIT
              else
                break
              fi
              MAX_BIND_ATTEMPTS=$((MAX_BIND_ATTEMPTS-1))
          done
        done < $DEV_LIST
      fi
      rm $DEV_LIST 2>/dev/null
}

    case "$1" in
      hibernate|suspend) unbindDev;;
      resume|thaw)       bindDev;;
esac
Pour le hibernate, il faut ajouter au kernel le nom du device de swap avec le paramètre resume. On peut ajouter dans /etc/default/grub, les options en automatique (généré avec grub-mkconfig) :
GRUB_CMDLINE_LINUX_DEFAULT="quiet add_efi_memmap resume=$(swapon -s | grep '/dev/sd.[0-9]' -o)"

samedi, janvier 7 2012

Archlinux 2 - Le retour et install en chroot

Mon OS de base est Sabayon duquel je suis assez satisfait.
Tout y est si bien intégré que l'on fait pas beaucoup de système par contre il y a quand même beaucoup de choses installées (OS installé en 2010 à partir de le 5.4 kde), ca manque de frugalité.
Un autre point un peu ennuyeux de Sabayon est que la communauté est pas très grande, ca donne un coté intimiste mais il y a quand même peu d'activité sur le forum (il y a aussi peu de problèmes donc !), ca manque un peu de vie.
Je suis donc toujours à la recherche d'une distro simple et légère, j'ai préféré testé une gentoo, la mère de sabayon qui m'a permis d'apprendre pas mal de choses dont l'install en chroot.
Cette méthode consiste en gros à monter une partition dans un répertoire et de définir ce répertoire comme étant le "root" du shell.
Ce qui est intéressant c'est que avec un minimum de config on peut installer, updater et administrer la distrib gentoo à partir d'un autre OS, pas besoin de cd, clé usb ou même de reboot (hormis pour utiliser cette nouvelle installation).
Sans rentrer dans le détails gentoo c'est encore plus souple que sabayon car du à la compilation on a vraiment énormément de prise sur le système (les USE flag) et sur les versions des logiciels à installer.
C'est très bien fait, propre, clair avec une excellente doc mais mais ca prends du temps à compiler !
Voulant tester Arch linux depuis un moment j'ai utilisé une méthode d'installation en chroot sur mon portable.
La méthode générale est dans ce wiki, J'avais un peu galéré avec l'install via le cd mais la ca marche tout seul.
Il faut suivre toute la partie 3 qui permet en fin de tuto de booter sur un archlinux qui est vraiment minimal, pour rendre un système quasi opérationnel (avec wifi, X, openbox), voici les étapes supplémentaires (après le mkinitcpio).
  1. pacman -S grub2-bios
  2. Installation de grub2 pour avoir quelques outils pratiques type grub-mkconfig(remplace grub)
  3. pacman -S openbox obmenu obconf tint2
  4. Installation de openbox et des outils de configuration (à noter que openbox ne depends pas de ses outils de conf)
  5. pacman -S xorg-server
  6. Installation du server X
  7. pacman -S xf86-video-intel
  8. Après vérification du package par :

    pacman -Sg xorg-drivers | grep intel

  9. pacman -S sudo wicd
  10. wicd pour configurer simplement le wifi en nomade et sudo car su semble trop sécurisé.
  11. edit /etc/rc.conf
  12. Pour ajouter le démarrage de dbus et wicd :
    DAEMONS=(syslog-ng network crond dbus wicd)
  13. Configurer les locales
  14. edit /etc/locale.gen et choisir les locales dédirées.
    locale-gen
    locale -a
    Il faut aussi changer LOCALE,KEYMAP,TIMEZONE dans le rc.conf
  15. Configurer grub
  16. Dernière étape, j'utilise un grub multiboot sur mon portable, configurer le grub.cfg de sabayon pour ajouter une entrée arch.
    grub-mkconfig -o /tmp/grub.test
    Recopier la partir arch sur le /boot/grub/grub.cfg de l'OS hote.
    
    Sortir du chroot, umount dev/sys/proc, sync et reboot.
A cette étape on a un OS fonctionnel sous Arch/X/Openbox. On peut se connecter au wifi via wicd-curses si jamais on a des problèmes avec X11 pour installer les packages nécessaires (démarrage de X par xinit /usr/bin/openbox-session car pas de gestionnaire de connection). Il ne reste plus qu'à ajouter les packages pour agrémenter tout ca (firefox, vlc ...).
La prochaine étape sera de configurer un KDE si possible light, installer tous les logiciels que j'utilise sous sabayon et de faire un bout de route sous Arch pour comparer.

jeudi, décembre 15 2011

Fedora et packagekit

L'integration de packagekit/gnome/fedora devenant très tenu il n'est plus possible d'enlever le package.
C'est très ennuyeux car il tourne sous chaque compte utilisateur et est très peu approprié pour une gestion centralisée des configurations des machines.
Il semble que la direction prise par fedora est de dire que il faut que la distro soit faite de tous les composants comme le temoigne la querelle de ce bug.
Heureusement j'ai trouvé comment empecher packagekit de tourner (grace à ce post) :
vi /etc/yum/pluginconf.d/refresh-packagekit.conf
=> enabled=0

mercredi, mai 11 2011

Installation arch linux notes et commentaires

Ma sabayon fonctionne très bien mais la communauté est assez petite et les documentations pas top top.<br />
Curieux des autres distro, je me lance dans une installation de arch linux qui semble allier la qualité des docs gentoo, le rolling release en binaire de sabayon et le foisonnement de ubuntu.<br />
J'ai fais ca sous virtualbox, le but est de voir comment se faire un desktop complet pour éventuellement l'utiliser à la place de Sabayon (ou bien en fifty/fifty).
Le but est de garder ca sous le coude pour la prochaine tentative ou bien eventuelle migration.
Un test en vbox ne peut pas être plus qu'une mise en bouche.
  1. Installation
  2. Elle se fait à l'ancienne pas forcement désagréable, il faut un minimum maîtriser son sujet (partitionnement, réseau et autres bases).
    Pas de gros problèmes hormis le partitionnement un peu capricieux qui avait tendance à se crasher (la faute à Vbox ?).
    Tout se passe en mode texte, A mon avis pas accessible à un débutant pas vraiment motivé.
    On se retrouve toujours à l'ancienne avec un jolis prompt # et c'est tout.
  3. Premier setup
  4. Un truc important, passer en français en mode de commande :
    loadkeys fr
    Par contre ensuite il faut tout se taper manuellement ...
    1. Config du language
    2. LOCALE="fr_FR.UTF-8"
      TIMEZONE="Europe/Paris"
      KEYMAP="fr-latin9"
      CONSOLEFONT="lat9w-16"
      CONSOLEMAP="8859-15"
      
    3. Config reseau
    4. lo="lo 127.0.0.1"
      eth0="dhcp"
      INTERFACES=(lo eth0)
      ROUTES=(!gateway)
      
      puis redemarrer le reseau :
      /etc/rc.d/network restart
    5. Synchro de packages et ajout de KDE
    6. # update repo
      pacman -Sy
      # upgrade derniere version
      pacman -Syyu
      # install kde
      pacman -S kde-meta-kdebase
      
    7. Conclusion
    8. L'OS est vraiment léger, les fichiers de config sont simples et assez naturelles.
      Reste la syntaxe un peu originale de pacman mais ca devrait pas poser de problèmes.
      Par contre c'est vraiment sans filet et on a vite tout cassé.
    Erreur fréquente
    error: could not open file /var/lib/pacman/sync/core.db: Failed to open '/var/lib/pacman/sync/core.db'
    
    Pour corriger :
    pacman-db-upgrade

mardi, avril 12 2011

Le jour ou tout marche

Quelques modestes petits succès de la journée.

1 - Major !
Les fontes sous KDE sont parfois pas terribles surtout sous FF et autres GTKs apps.
Une super solution qui rends les choses presques parfaites.
Editer le .fonts.conf suivante cette page.
Quelques explications dans le forum gentoo (avantage de sabayon !).
Ca reste à creuser si je trouve le temps d'investiguer.
Il me reste plus qu'à tester si ca améliore le rendu assez mauvais des suse au boulot.

2 - Evidement pour editer du xml vi c est pas top.
Je trouve l'appli idéale pour editer simplement du xml sous QT !
Disponible dans entropy QXmlEdit.


3 - Satané VFAT Enfin ma clé USB ne voulait pas se monter en rw.
A noter que sur kubuntu ca se montait en RW alors que le fs etait corrompu ...
Après maintes recherches, l'option qu'il fallait (formattée en vfat) :

fsck -r  /dev/sdb1

3 problèmes de réglé en 15 minutes :-)

Il faudrait aussi que je me renseigne sur udev et les montages automatiques.
Les fichiers de conf me reste assez etrangers...
Encore dans les excellentes docs de gentoo.

vendredi, février 25 2011

Purger les vieux kernel sous Sabayon

A force d'installer des nouveaux kernels (via entropy), ça s'entasse sur mon système.
On commence par un purge des fichiers d'install de entropy :
equo cleanup
Ensuite on regarde les kernels installés (le kernel courant est celui suivis d'une *) :
sabayon ~ # eselect kernel list
Available kernel symlink targets:
[1]   linux-2.6.34-sabayon
[2]   linux-2.6.35-sabayon
[3]   linux-2.6.36-sabayon
[4]   linux-2.6.37-sabayon *
Je choisis de purger le .34.
sabayon ~ # equo query installed 2.6.34-sabayon | grep Paquet
@@ Paquet: app-emulation/virtualbox-guest-additions-4.0.2#2.6.34-sabayon branche: 5, [__system__]
@@ Paquet: app-emulation/virtualbox-modules-4.0.2#2.6.34-sabayon branche: 5, [__system__]
@@ Paquet: app-laptop/omnibook-20090628-r1#2.6.34-sabayon branche: 5, [__system__]
@@ Paquet: net-firewall/ipset-4.3#2.6.34-sabayon branche: 5, [__system__]
@@ Paquet: net-wireless/broadcom-sta-5.60.48.36-r1#2.6.34-sabayon branche: 5, [__system__]
@@ Paquet: net-wireless/ndiswrapper-1.55-r1#2.6.34-sabayon branche: 5, [__system__]
@@ Paquet: x11-drivers/xf86-video-virtualbox-4.0.2#2.6.34-sabayon branche: 5, [__system__
La il faut faire attention à bien avoir une version plus récente des packages que l'on s'apprete à enlever. On peut scripter ca :
for i in $(equo query installed 2.6.34-sabayon | grep Paquet | awk -F ':' '{print $2}' | sed s/-[0-9].*//) ;
do
equo query installed $i | grep Paquet
echo
done
Qui donne grosso modo tous les package qui comprennes une version de kernel. On peut donc enlever tous les packages correspondant à la version cible. Si il n'y a pas de version correspondante au kernel courant il peut etre sage de reinstaller le package par la suite. Dans mon cas j’obtiens la liste suivante :
@@ Paquet: app-emulation/virtualbox-guest-additions-4.0.2#2.6.34-sabayon branche: 5, [__system__]
@@ Paquet: app-emulation/virtualbox-modules-4.0.2#2.6.34-sabayon branche: 5, [__system__]
@@ Paquet: app-emulation/virtualbox-modules-4.0.2#2.6.36-sabayon branche: 5, [__system__]
@@ Paquet: app-emulation/virtualbox-modules-4.0.2#2.6.37-sabayon branche: 5, [__system__]
@@ Paquet: app-laptop/omnibook-20090628-r1#2.6.34-sabayon branche: 5, [__system__]
@@ Paquet: net-firewall/ipset-4.3#2.6.34-sabayon branche: 5, [__system__]
@@ Paquet: net-wireless/broadcom-sta-5.60.48.36-r1#2.6.34-sabayon branche: 5, [__system__]
@@ Paquet: net-wireless/ndiswrapper-1.55-r1#2.6.34-sabayon branche: 5, [__system__]
@@ Paquet: net-wireless/ndiswrapper-1.56#2.6.36-sabayon branche: 5, [__system__]
@@ Paquet: x11-drivers/xf86-video-virtualbox-4.0.2#2.6.34-sabayon branche: 5, [__system__]
@@ Paquet: x11-drivers/xf86-video-virtualbox-4.0.2#2.6.36-sabayon branche: 5, [__system__]
Au final je :
equo remove omnibook-20090628-r1#2.6.34-sabayon ipset-4.3#2.6.34-sabayon net-wireless/broadcom-sta-5.60.48.36-r1#2.6.34-sabayon
equo remove x11-drivers/xf86-video-virtualbox-4.0.2#2.6.34-sabayon ndiswrapper-1.55-r1#2.6.34-sabayon
equo remove sys-kernel/linux-sabayon-2.6.34
Je reinstalle les version recentes des packages manquants :
equo install x11-drivers/xf86-video-virtualbox-4.0.2#2.6.37-sabayon
Et voila.

vendredi, janvier 14 2011

Valider la page admin tomcat et sécuriser les mots de passe

J'ai installé tomcat 5.5 (5.5.31) dans le repertoire /opt/tomcat.
Après l'installation je me connecte à la page d'admin et :

Tomcat's administration web application is no longer installed by default. Download and install
the "admin" package to use it.

Diantre que diable dois je faire ?
Installer le webapp d'admin bien sûr à recupérer sur :
http://archive.apache.org/dist/tomcat/tomcat-5/v5.5.31/bin/
C'est un tar qui part de la racine de tomcat .. Par terrible.
Le placer dans le repertoire webapps puis restart, on voit bien l'application mais à chaque fois que l'on se connecte sur /admin on a toujours le même message.
Il faut retirer le fichier index.html de : /opt/tomcat/webapps/ROOT/admin et miracle ca fonctionne.
Pour les utilisateurs il faut aller dans le fichier ; /opt/tomcat/conf/tomcat-users.xml.
Ajouter des roles pour manager et admin puis les users.
Le mot de passe est en clair, pas terrible.
Pour crypter les mots de passe il faut aller dans le server.xml et changer le "digest" (un peu à la mode apache d'ailleurs)...
Ajouter au niveau de (en dessous)
Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"

digest="MD5"
digestEncoding="UTF-8"

Ensuite on peut mettre un passwd md5 dans le fichier tomcat-users.xml et redemarrer tomcat.
A noter que le md5 est peut etre pas le plus secure.

jeudi, janvier 6 2011

Monter des partitions LVM en bootant sur un OS different

Suite à un probleme de boot, j'utilise un livecd mais je ne peux pas monter les partitions car les devices n'existent pas bien que le lvdisplay fonctionne.
Utiliser sfdisk -l pour voir les partitions, celles de lvm sont sous la forme : /dev/vg/volume

% su -
# modprobe dm-mod
# vgchange -a y
  • modprod : pour charger le module lvm
  • vgchange : pour activer tous les volumes group
Ensuite on peut voir le FS et le monter en utilisant le path mount /dev/vg/volume ...

- page 1 de 2