lundi, janvier 19 2015

Using several PXE servers on one DHCP: chaining!

In large environment, most enterprise software provide All-in-one solutions, they manage the computer since the boot. Fixing one PXE server in the DHCP profile for a computer, makes it hard to adapt for other usage.

Lire la suite...

mardi, avril 29 2014

OSX: what is Netboot and using it with linux

Netboot is a technology created by Apple to boot computers on the network like PXE. OSX Server integrates a daemon for this service. It uses a extension of DHCP, known as Boot Service Discovery Protocol BSDP

Lire la suite...

dimanche, septembre 16 2012

XFCE et XRDP

XFCE4 presente , lors de la déconnexion, le bouton deconnexion. Cependant , lorsque la session est locale, il rajoute les boutons shutdown, reboot, hibernate.

La où ce n'est pas de chance, c'est que xrdp, crée des sessions pour les utilisateurs à distance, et ces sessions semblent vu comme étant locale. Alors forcement, s'il y a un utilisateur qui sélectionne shutdown, les autres le subissent également.

La manipulation est asez simple: interdire le shutdown à des users:

Créer /etc/xdg/xfce4/kiosk/kioskrc avec:

   [xfce4-session]
   Shutdown=root

La solution propre est de dire d'un coté que, même sur la console, seul root peut faire un shutdown, et que xrdp doit annonce ses sessions comme étant distantes

vendredi, août 24 2012

Le RAID ce n'est pas pour les autres

La panne!

Cela devait arriver (et ca vous arrivera, Murphy est la pour ca):

  Aug  5 06:25:34 sophie mdadm[1199]: Fail event detected on md device /dev/md0, component device /dev/sdb1

Disque HS, heureusement, le serveur a ses données sur des disques RAID (RAID0, mode mirroir).

Lire la suite...

jeudi, mars 8 2012

Haute dispo, la suite: serveur NFSv4 en Master/Slave

48 heures entre les deux articles, c'etait un poil moins simple...
Pré-requis: savoir faire un DRBD et passer de l'un a l'autre.

Le but est de monter deux VM avec IP1 et IP2, et avoir une IPV qui sera attaché soit à VM1ou VM2 suivant qui aura le service nfsv4. Chaque VM se partage via DRBD le stockage. La machine primary a le montage du disque /local et le service nfs. Comme c'est du NFSv4, c'est statefull, donc le /var/lib/nfs contient des informations importantes à mettre à disposition de l'autre VM en cas de bascule. Et le service nfs ne demarrera pas sans ce dossier -> Il sera mis sur le /local dans un dossier ".private", et /var/lib/nfs sera un lien symbolique vers ce répertoire. Le délai de bascule est de 90s suivant le contenu de /proc/fs/nfsd/nfsv4leasetime

Les logiciels

apt-get install pacemaker drbd8-utils nfs-kernel-server psmisc; update-rc.d drbd disable 2; update-rc.d nfs-kernel-server disable 2
On retire les scripts, c'est le pacemaker qui va demarrer lui même les services, et il aime pas quand c'est pas lui qui fait le boulot (psmisc est nécessaire pour avoir /bin/fuser, j'ai passé 4h dessus pour vous).

La conf Corosync

Puis sur le serveur VM1, changer le demarrage automatique, et le fichier de conf de /etc/corosync/corosync.conf

sed -i 's/START=no/START=yes/' /etc/default/corosync

interface {
            ringnumber: 0
            bindnetaddr: AAA.BBB.CCC.DDD
            mcastaddr: 224.0.0.EEE 
            mcastport: 1974
    }

Mettre une EEE entre 128 et 200 pour suivre les RFC. AAA.BBB.CCC.DDD est votre IP virtuelle IPV

Générer une clef et la copier sur l'autre serveur, puis redemarrer les services corosync

corosync-keygen
scp /etc/corosync/authkey VM2:/etc/corosync/authkey
scp /etc/corosync/corosync.conf VM2:/etc/corosync/corosync.conf
scp /etc/default/corosync VM2:/etc/default/corosync

Sur la VM1 primary

mount /dev/drbd1 /local
mkdir /local/.private
mv /var/lib/nfs /local/.private/

Etre sur d'avoir bien arreté les serveurs NFS sur les deux VM, puis sur les deux serveurs:

rm -fr /var/lib/nfs; ln -s /local/.private/nfs /var/lib/nfs

La conf Pacemaker

Un outil qu'il est bien.

crm configure edit vous lance un bon vieux vi de derrière les faggots.

node VM1 \
       attributes standby="off"
node VM2 \
       attributes standby="off"
primitive p_drbd_VMS ocf:linbit:drbd \
       params drbd_resource="VMS" \
       op monitor interval="20" role="Master" \
       op monitor interval="30" role="Slave"
primitive p_fs_vms ocf:heartbeat:Filesystem \
       params device="/dev/drbd1" directory="/local" fstype="ext3" \
       op monitor interval="30s"
primitive p_ip_nfs ocf:heartbeat:IPaddr2 \
       params ip="AAA.BBB.CCC.DDD" cidr_netmask="ZZ" \
       op monitor interval="10s"
primitive p_nfs_service lsb:nfs-kernel-server \
       op monitor interval="10"
group g p_fs_vms p_ip_nfs p_nfs_service
ms ms_drbd_VMS p_drbd_VMS \
        meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
colocation c_drbd_and_mount inf: ms_drbd_VMS:Master g
order o_drd_before_fs inf: ms_drbd_VMS:promote p_fs_vms:start
order o_nfsservice_after_fs inf: p_fs_vms:start p_nfs_service:start

Changer dans property, ce qui va bien:

property $id="cib-bootstrap-options" \
        stonith-enabled="false" \
        no-quorum-policy="ignore" 
...

Les primitives commencent par un p_ et sont utilisé ensuite dans les autres objets. On peut definir un type d'objet comme ms pour Master/Slave, grouper un ensemble d'objets, comme ici le fait d'avoir l'IP le service nfs et le filesystem monté.

Le groupe est juste la pour pouvoir simplifier les écritures. Si on veux que ces services tournent sur le même serveur, il faut dire qu'ils sont localisé au même endroit avec colocation. A charge de pacemaker de résoudre les contraintes pout qu'ils arrivent tous au meme endroit.

L'ordre de démarrage étant important, on peut le spécifier via les order. Attention, si un order échoue, le système peut basculer l'ordre en sens inverse.

Les commandes qui vont bien pour crm

Pour basculer d'un serveur a l'autre:

crm_ressource --resource p_nfs_service --move

Pour faire oublier des erreurs d'une primitive, par ex le montage du drbd:

crm_ressource --resource p_fs_vms --cleanup

Conclusion

Encore une techno que j'aurai du mettre en place dès le début. Me fallait juste du temps pour tester ...

mardi, mars 6 2012

Haute dispo

La haute dispo, ou comment dormir la nuit

A force de créer des machines virtuelles pour offrir du service, il fallait penser aussi à offrir de la qualité de service. rapide calcul, 40 VM stocké sur un serveur NFS, il est peut etre temps d'avoir un peu plus qu'un PRA depuis des backups.

Et puis le serveur NFS, il a besoin de place, ces VM, ca a un appetit sans fin!

Au debut ca marche, et plus le temps passe, plus la co**le va finir par arriver. C'est comme pour les backups, sauf que la, je vais pas attendre.

Les promesses

  • NFS4 ca permet la replication des données. directement configuré coté client.

/data -vers=4,replicas=/data@account1:/backup/data@inreserve

Sauf que le replicat, il est en lecture seule, donc a part pour des cas particuliers comme ces gens qui serveur des pages ouaib, ca va pas me servir des masses.

  • GFS2, OCFS2, MOOSEFS : Leurs avantages, c'est qu'on peut les monter en actif/actif sur deux serveurs en meme temps, et donc y ecrire en meme temps (ceux qui pensent que NFS ca fait pareil, ils vont devoir prendre quelques cours). "Distributed Parallele Fault Tolerent Filesystem", c'est super bien, mais ca demande au moins autant de serveurs differents qu'il y a de mots.

K.I.S.S.: Keep it simple, stupid: DRBD

J'ai pas besoin d'une arme de guerre. j'aimerais avoir un mirroir de mes données en temps reel sur un autre serveur. Pas besoin de 36000 Trasnsactions par seconde sur le serveur. un bon vien RAID1 ca sera suffisant. Ca tombe bien DRBD ca sert à ca. Fallait juste trouver 12h dans une journée.

Plus simple tu meurs

Pour les ceuces qui découvrent l'informatique, drdb, c'est un device, ca s'utilise comme un disque. Et en dessous, on designe les deux serveurs qui vont stocker les données (le local et un distant). Pour la conf , on rajoute une fichier de meme nom que sa ressource dans /etc/drbd.d/.

 resource VMS {
 on serv1 {
   device    /dev/drbd1;
   address   192.168.1.1:7789;
   disk      /dev/sdb1;
   meta-disk internal;
 }
 on serv2 {
   device    /dev/drbd1;
   address   192.168.1.2:7789;
   disk      /dev/sdb1;
   meta-disk internal;
 }
 }

les deux IP sont celles des deux serveurs, sur un lien dédié, mais on peut aussi utiliser les interfaces standard.

C'est a faire sur les deux serveurs Ensuite, on initialise le device: drbdadm create-md VMS et on lance la connexion et synchro avec drbdadm up VMS. Il reste a decider qui sera le serveur primaire: drbdadm primary --force VMS à faire sur le serveur désigné.

Et voila vos pouvez faire un cat /proc/drbd pour voir le status de vos disques.

Passer primaire ou secondaire, synchroniser

L'etat normal est d'avoir un

 cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate

Pour changer de l'un a l'autre, passer les deux en Secondaire, puis passer le Secondaire en Primaire.

 drbdadm primary  VMS

Pour lancer une synchro:

 drbdadm syncer  VMS

Pour connecter le disque:

 drbdadm connect  VMS

A l'utilisation

Sur le primaire, on met son FS comme un disque classique:

 mkfs.ext3 /dev/drbd1

et roule ma poule

Sur le secondaire, vous ne pouvez rien faire. Meme pas monter le device en lecture seule.

Si votre primaire A tombe, c'est le moment de savoir quoi faire sur le secondaire B:

  • aller sur le secondaire B
  • le passer en Primaire
  • Monter sa partoche

Et quand le A reviendra

  • forcer le A en secondaire
  • synchroniser les données

Et se demander si on reechange A et B

jeudi, mars 1 2012

The State of remote acces, NX, RDP

The past

X11 is the default implementation of the graphic GUI onto unix platform. The protocol used to display application is network aware. Since 25 years all unix flavour can start a remote applications and display them onto networked display.

xterm -display hostname:0

The XDMCP protocol has started the thinclient model, where only a X server and a TCP/IP base is inclused in the thinclient, whereas all memory and CPU task are computed on the main server.

The main problem with X11 is the complexity of the implementation for the developper, and for the user experience, the non-LAN usage: there are a lot of roundtrip between the X server and the X client, making the whole unusuable on slow links (i.e. more than 50ms latency). Classical number of roundtrip for starting a classical X application is over 2000.

  • Local application, latency under 0.1ms -> 1000*0.1ms makes it start in 100ms
  • Remote application, latency of 40ms -> 1000*40=40000 =40s

Now

Nowadays applications use a lot of graphics effects, requiring a composite server. this task is CPU intensive, and tries where made to extend the protocol to do it remotely, but thinclients weren't designed for that.

VNC

the VNC protocol, which came up because windows had no network capabilities for the display, is a framebuffer technology. Better on the network level, the latency doesn't influence so much on quality. but as a framebuffer techno, it displays a opened session only, and the server isn't aware of the location of the user.

NX

NX tries to solve the problem of the X latency, by adding two proxies between the X client and the X server so it can reduce the number of roundtrip. NX has opened the X protocol on medium and large latency network, which make it usuable even on a modem connected network with roundtrip up to 500ms Up to version 3, NX was open source, based on a XFree 4 code. But the fork from XFree4to xorg was not followed by the compagny supporting the NX developement, and the version 4 won't be open sourced. The NX won't probably be updated to match further development of xorg, and will die slowly. Other actor on this technology was google which probided an NX server implementation named neatx

RDP

is the microsoft contribution to the remote access. Since 10 years, only the server was available onto windows server (NT4, 2000, and later). It's a part of the T128 ITU norm. and based on the Citrix code. The protocol is fast and is based mostly on a remote framebuffer, but the server is aware of the network part.

Since 2007 and the Antitrust action, the protocol specification are available. the RDP protocol does more than only transport the disply on another device. There is also a place for remote sound, data transport,port redirection and even a composite extention (X11 can only transport display, VNC has some chat and filetransfert capatilities)

The future

RDP

There was a reverse engineered server for X11, named xrdp, which provided an RDP access to an X11 server but the protocol was very basic.

The FreeRDP project has implemented in 2012 an (proof-of-concept) X11 application which expose the desktop through RDP. There is still some work to do, but is very promising.

Wayland

Some people want to rethink the most GUI part in linux. the networked X11 is no more adapted to the actual use of computers, and the network part is only used by a minority of users (but users starting X11 applciation through a ssh connection are common...) Wayland

SPICE

This protocol has been designed by redhat to export display and devices to client, in a VDI project. the project is active and the protocol is open

PCoIP

This is a new proprietary protocol, developed by teradici which is implemented in vmware.

Where to go ? :)

IMHO, RDP will be the best way to go for providing users a remote access to a desktop. For managed workstations or VDI, PCoIP or SPICE could be the solution, but PCoIP is fully proprietary :(

vendredi, décembre 23 2011

Garmin forerunner & linux

I'm a owner of a Garmin Forerunner 305. To use it under linux, there are two ways.

Use of my.garmin.com

There is a plugin to install on firefox to be able to retrieve data from the garmin, and send data to the website my.garmin.com . Simply add the following repository in ubuntu/debian and install garminplugin

sudo add-apt-repository ppa:andreas-diesner/garminplugin

sudo apt-get update

sudo apt-get install garminplugin

The main page for this project is http://www.andreas-diesner.de/garminplugin

Local use of data

In the first part, data are all uploaded and stored by garmin. you have no data on your computer, and you can't get them! In linux, you can store the data from the forerunner with the following program, available in the normal repository, with garmin_save_runs. The package name is garmin-forerunner-tools . The main website for the project is http://code.google.com/p/garmintools/ . Now you are able to convert these data and end them to different programs

lundi, décembre 19 2011

La fin d'une époque

Dans des temps très lointains, quand je suis arrivé à l'IUT, j'ai découvert une salle serveur, où il n'etait pas possible d'arriver au bout de la piece de 4x8m.

Des tours partout, sur des tables, sur des étagères, des cables tirés directement depuis une petite armoire de brassage... Depuis, quelques années se sont écoulées, des mises à jour et des mises au carré ont permis de faire le ménage

Ce soir, j'ai éteint le dernier PC de la dernière étagère, après l'avoir virtualisé...

Avant:

pipit OLD

Après:

pipit-new.jpeg

vendredi, mai 16 2008

Replacing ghost with tools for real men. Part3: Computers are here to work, not me. Multicast is for you.

Testscase was ok, it was time to script everything, and let computers works alone. Mostly. Using udp-cast, I got a better solution than NFS or netcat: same speed, and over 16 clients at the same time. And so easy to deploy ...

Lire la suite...

- page 1 de 4