Reprise du message précédent :
 
rapport avec un onduleur?
edit : j'ai capté mais je vois toujours pas
j'ai pourtant regarder les billets qui parlaient de cette erreur et je ne vois aucun souci.
j'ai juste branché un onduleur sur un eeepc701 et je veux juste obtenir le status/parametres de l'onduleur.

Ca ressemble plus à une interface avec un onduleur
Peut-être se rajouter à un groupe ?
 
XaT

je suis en root pour "le moment" et le modèle d'onduleur me semble etre un truc "basique".
et le bouzin demarre correctement
root@eeepc701-server:~# service apcupsd restart
Stopping UPS power management: apcupsd.
Starting UPS power management: apcupsd.

Faut surtout installer le service qui permet d'interroger l'onduleur (apcupsd). Rien à voir avec CUPS, même si ça apparait dans le nom du programme recherché (c'est APC UPS Daemon)

Regarde si le daemon tourne bien et qu'il ne couine pas dans ses logs ?  
 
XaT

j'ai édité  j'ai tout suivi normalement

root@eeepc701-server:~# cat /etc/default/apcupsd
# Defaults for apcupsd initscript
 
# Apcupsd-devel internal configuration
APCACCESS=/sbin/apcaccess
ISCONFIGURED=yes
 
par contre j'ai pas encore testé l'extinction auto de la machine

 
/etc/apcupsd/apcupsd.conf
 
Je pense aux lignes de conf' UPSCABLE et UPSTYPE

Ca ne veut pas dire que le service tourne
 
faut faire un status, et sinon regarder si t'as bien le démon en écoute sur le port 3551 en local (netstat -taupn | grep 3551)

en effet, c'était mis en smart alors qu'il est branché en usb . j'ai fait le changement mais le résultat est le même

Et t’as relancé le daemon, bien sûr.

bien sur  
après avoir viré apcupsd et mis nut à la place et qui ne fonctionnait pas mieux  
j'ai fini par trouvé  (merci à mystX qui m'a mis sur la bonne piste)
en fait je m'obstinais à mettre DEVICE /dev/ttyUSB3 (vu qu'il est brancher la dessus ) dans la conf    
et en fait il faut laisser DEVICE sans aucun renseignement

toujours preums

 
Si tu veux j'ai des bons somnifères.

Bon bah deu'z

Pour moi ce sera une bouteille de Mercurey 1er cru.

 
Je pensai plutôt à un coup de batte sur le coin du museau.  

clos saint jacques pour moi svp

et dern'z
        \
 

Bonlut,
 

 
hého !  

mes invocations marchent de moins en moins bien ...

C'est depuis qu'il a migré vers Gapps ça

Bah merci alors

Je cherche des alternatives à GFS2 svp Si j'ai bien compris, c'est du « Shared-disk file systems ».

Le but, c'est d'être capable d'écrire des fichiers sur un SAN block only (iSCSI), sans se marcher dessus à plusieurs hôtes. Comprendre que chaque hôte peut écrire dans un endroit sans écraser le voisin.

La première approche « naïve » c'est d'utiliser LVM pour segmenter le block device en morceaux (mais c'est pas thin pro du coup, faut prendre des morceaux entiers). L'autre possibilité c'est d'utiliser GFS2 en mode cluster (avec corosync donc) et écrire des fichiers là dedans (fichiers VHD ou qcow2 pour grossir au besoin)

Ma connaissance du iSCSI est pas assez bonne, existe-t-il des commandes iSCSI pour réserver des morceaux d'une grosse LUN ? (je voudrais éviter 1 LUN = 1 disk de VM, je trouve ça pas pratique du tout).

J'ai pas trop d'idée là

Comme remplacant de GlusterFS je sais pas.
Mais sinon t'as regardé si CLVM (Cluster LVM) répondait pas à ton besoin ?

 
Lustre, Hadoop, CEPH.

+1 pour ceph

fixed.

dern'z de circonstance  

Preums

Deu'z

 
Je suis plus vieux    
 

 
Mon bot écrit en Gscript déconne tout le temps mais pas sur que ce soir à cause de Gscript  
 

Comme le temps ?

Il me semble que ces 3 là sont plutôt orientés stockage distribué sur plusieurs noeuds (avec stockage local), plutôt que gestion des accès concurrents à un stockage centralisé.
Ou alors j'ai pas pigé la demande de Ploum

Ta très bien pigé ma demande, c'est exactement ça

Je cherche juste un FS pour accès concurrent à stockage block centralisé

edit : ou un moyen de « découper » ces blocks pour chaque disque de VM pour pas se marcher sur les pieds.

En Open Source, j'ai l'impression que y a que GFS2 (qui ne semble pas te convenir) et OCFS2.
Après y a des produits proprios, mais je pense pas que ça va coller à ton cahier des charges.
 
Aucune expérience avec ni l'un ni l'autre pour ma part.
 
Sinon t'as regardé CLVM ? Ca peut répondre à ta problématique de découpage.

En théorie j'ai même pas besoin de cLVM, puisqu'avec juste LVM, XenServer/XCP a conscience de qui à le verrou sur quel logical volume (notion de pool)

Le problème étant la façon de faire de la réservation d'espace qui fait que c'est pas thin pro

Sinon reste l'idée de faire des « réservations » via des commandes iSCSI, mais j'ignore complètement ce qu'il est possible de faire ici.

edit : je vais zieuter OCFS2

iSCSI, c'est jamais que du SCSI, donc je ne pense pas que ça puisse faire ce que tu attends.

 
Ils sont pour les deux : accès concourants (et pas concurrents, ils ne sont pas en compétition, ils doivent juste être faits en même temps) et nœuds multiples. Puisque leurs intérêts est avant tout l'accès concourant, le nœuds multiples n'importe quel FS évolué sait le faire.
 
Et pour des solutions "many clients" en mode block, y'en a pas des masses : CEPH, HDFS, Lustre et Openstack. Openstack, c'est clairement de la merde. Reste les 3 autres qui sont facilement implémentable.
 
Edith: j'exclue RozoFS volontairement. Et les solutions microsoft basées sur Lustre, ainsi que les solutions EMC qui coûtent un bras.
Edith 2 : Accéder à plusieurs nodes depuis 1 client unique, c'est du raid. Il veut l'inverse du raid (un block, plusieurs accès).

J'ajoute donc dans le cahier des charges : la solution la plus simple/légère pour un petit nombre de nœud (de 2 à 16 graaaand max).
 
Il s'agit juste de partage un storage block en morceau

CEPH ou HDFS. Préférence pour CEPH.
 
Edith : précision, à partir du moment ou tu veux faire du many client, t'es obligé de passer par un driver dans les clients pour accéder au block/objects, y'a rien de natif qui existe puisque tu as besoin de composantes de type lock et que tout les clients soient au courant. Par définition, en fait, se que tu cherche n'existe tout simplement pas : tu ne peux exposer, quelque soit le protocol, du block storage a plusieurs clients en même temps sur un partitionnement unique. Il n'existe pas de protocole block (iSCSI, SATA, Whatever) capable de faire ça, puisque systématiquement les LUN sont lock à partir du moment ou tu y accède.
De facto, il faut passer sur de l'object storage.