FRsAG

frsag@frsag.org

10 participants
2597 discussions

Hotcity recrute un Sysadmin (avec un peu de réseau dedans aussi).
by Xavier Beaudouin 24 Nov '21

24 Nov '21

Bonjour, Je fais suivre l'offre de ma boite, Hotcity (située à Luxembourg, la ville pas le jardin à Paris). L'offre est adressée à des gens qui veulent bosser au Luxembourg. Il y a possibilité de télétravail bien évidement même si au démarrage c'est plutôt mieux avec un peu de présence (la bande passante pour les informations est plus grande !). Avant de m'attirer les FUDs de la non information de la rémunération, sachez que le salaire est assez attractif, même pour le Luxembourg.... Open Off-list pour des clarifications, ou des renseignements... Sachant que je serai un collègue direct. --//-- Afin de renforcer les équipes de HOTCITY S.A., nous sommes à la recherche d’un Administrateur Systèmes (CDI), parlant Français (tout autre langue constitue un avantage) Lieu : Luxembourg Ville Temps plein (40h/semaine) Vous assisterez l’équipe actuelle à : - La mise en place de nouveaux services (infrastructures WiFi, hébergement d’applications, …) - La bonne évolution des systèmes d’informations (optimisations, mises-à-jour, monitoring, …) - La mise en haute disponibilité de l’infrastructures de services (architecture, automatisation, documentation, …) Votre profil : - Expérience en administration système Unix/Linux : FreeBSD (jails, etc…), Debian, CentOS - Connaissances des environnement de virtualisation : VMware, BastilleBSD, vSphere - Maitrise des systèmes de stockage / backup / monitoring / automatisation - Expertise : HA, DNS, DHCP, SSH, HTTP(S), RADIUS - Compétences en DBA : MariaDB Galera Cluster, PostgreSQL - Passionné par le monde de l’OpenSource - Connaissances en réseau: IPv4/IPv6 souhaitées Vos collègues : - Des collègues expérimentés soucieux de vous donner le soutien nécessaire et capables de vous transmettre le savoir qu’ils ont acquis - Des supérieurs à votre écoute et ouverts à de nouvelles idées, suggestion et critiques - Une atmosphère jeune et détendue - Très faible fluctuation du personnel Offres & Avantages : - Bonne localisation à proxmité des transports en commun. Une place de parking est également envisageable - Tickets restaurant - Tickets train, respectivement place de parking - Télétravail possible - Rémunération à la hauteur du profile Si vous êtes intéressé par cette proprosition, veuillez nous envoyer votre candidature, accompagnée d’un CV détaillé et d’une photo à : direction(a)hotcity.lu. Plus d’info notre société : https://hotcity.lu/

1 0

Cherche machine type appliance 1U
by Sébastien 65 17 Nov '21

17 Nov '21

Bonjour, Je suis à la recherche d'un boitier 1U rackmount avec au minimum 4 interfaces LAN 1Gb et 2 ou 4Gb de RAM avec un disque SSD de 16/32 ou 64Gb ! Je souhaite pouvoir installer du Linux dessus pour faire un petit firewall... Je ne trouve pas grand-chose à des tarifs inférieurs à 250€HT. Sur Aliexpress il y a bien des produits qui me correspondent mais tous viennent de Chine, il n'est pas indiqué le prix du passage en douane ! Avez-vous une adresse d'un vendeur/importateur FR ? Merci

6 7

Bcache + LVM
by Frédéric Dumas 15 Nov '21

15 Nov '21

Bonjour à tous, quelques questions à propos de bcache. Je l’installe sur cette configuration matérielle: backend device /dev/sda = RAID6 hardware avec stripe size de 1024Ko cache device /dev/md0 = RAID1 software avec deux P3700 Le device /dev/bcache0 est créé avec ces paramètres : > # make-bcache --data-offset 1024k --bucket 2048k --writeback --bdev /dev/sda4 --cache /dev/md0 Le cache est bien attaché à son backend device: > # lsblk > NAME SIZE FSTYPE TYPE MOUNTPOINT > sda 7.3T disk > ├─sda1 1007K part > ├─sda2 512M vfat part > ├─sda3 31.5G LVM2_member part > │ └─pve-root 7.8G ext4 lvm / > └─sda4 7.2T bcache part > └─bcache0 7.2T disk > sr0 1024M rom > nvme0n1 745.2G disk > └─md0 745.1G bcache raid1 > └─bcache0 7.2T disk > nvme1n1 745.2G disk > └─md0 745.1G bcache raid1 > └─bcache0 7.2T disk Questions: (1) Quel est le erase block size sur le P3700 ? Je n’ai pas trouvé dans les specs Intel. Mon seul indice, c’est un message d’un développeur sur la liste LKML. La valeur 2048k donnée à l'option --bucket est-elle correcte ? (2) stride width = "stripe width » et aussi "stripe size" ? Extrait de la doc bcache: > If your backing device is RAID based, then be sure to align this by a multiple > of your stride width using bcache make –data-offset. L’option --data-offset attend-elle bien la valeur (dans mon cas 1024k) du stripe width de la grappe RAID6 ? Voilà un plus long extrait de la doc bcache: > Backing device alignment > > The default metadata size in bcache is 8k. If your backing device is RAID based, then be sure to align this by a multiple of your stride width using bcache make –data-offset. If you intend to expand your disk array in the future, then multiply a series of primes by your raid stripe size to get the disk multiples that you would like. > > For example: If you have a 64k stripe size, then the following offset would provide alignment for many common RAID5 data spindle counts: > > 64k * 2*2*2*3*3*5*7 bytes = 161280k Source: https://www.kernel.org/doc/html/latest/admin-guide/bcache.html#troubleshoot… (3) Dernière question: quand j’intègre le device /dev/bcache0 à LVM, ça passe mais avec des erreurs: > # pvcreate /dev/bcache0 > Error reading device /dev/bcache0 at 7965015146496 length 4. > bcache_invalidate: block (0, 0) still held > bcache_abort: block (0, 0) still held > Error reading device /dev/bcache0 at 7965015248896 length 4. > Error reading device /dev/bcache0 at 7965015259648 length 24. > Error reading device /dev/bcache0 at 7965015260160 length 512. > scan_dev_close /dev/bcache0 no DEV_IN_BCACHE set > scan_dev_close /dev/bcache0 already closed > Error reading device /dev/bcache0 at 7965015146496 length 4. > bcache_invalidate: block (0, 0) still held > bcache_abort: block (0, 0) still held > Error reading device /dev/bcache0 at 7965015248896 length 4. > Error reading device /dev/bcache0 at 7965015259648 length 24. > Error reading device /dev/bcache0 at 7965015260160 length 512. > Physical volume "/dev/bcache0" successfully created. Google reste muet sur « Error reading device /dev/bcache0 at », au moins pour moi. La définition du VG donne un retour similaire: > # vgcreate vms /dev/bcache0 > Error reading device /dev/bcache0 at 7965015146496 length 4. > bcache_invalidate: block (3, 0) still held > bcache_abort: block (3, 0) still held > Error reading device /dev/bcache0 at 7965015248896 length 4. > Error reading device /dev/bcache0 at 7965015259648 length 24. > Error reading device /dev/bcache0 at 7965015260160 length 512. > Error reading device /dev/bcache0 at 7965015146496 length 4. > bcache_invalidate: block (0, 0) still held > bcache_abort: block (0, 0) still held > Error reading device /dev/bcache0 at 7965015248896 length 4. > Error reading device /dev/bcache0 at 7965015259648 length 24. > Error reading device /dev/bcache0 at 7965015260160 length 512. > Volume group "vms" successfully created La création d’un LV dans ce VG ne renvoie par contre aucune erreur. Si quelqu’un a une hypothèse ? Merci! -- Frédéric Dumas f.dumas(a)ellis.siteparc.fr

2 1

Re: [FRsAG] ESXi VM backup lent 12Mo/s (Dell R710 SATA)
by Ludovic Levet 15 Nov '21

15 Nov '21

Bonjour, On parle d'un cp entre datastores locaux, on passe pas par le réseau. Ludo. Le 15/10/2021 à 06:41, Stéphane Karges a écrit : > Hello, > > Pb de drivers carte réseau, j’ai eu le pb par défaut la carte est en 100g et pas en 1000. Il y a eu manip pour prendre l’ancien drivers tu trouve sur internet. Cela réglera ton pb. > > Stéphane > > Envoyé de mon iPhone > >> Le 14 oct. 2021 à 23:03, Ludovic Levet via FRsAG <frsag(a)frsag.org> a écrit : >> >> Bonjour, >> >> A vérifier : >> >> - Présence de la barrette mémoire (cache) sur la la perc 700 >> >> - État de la batterie cache de la perc 700 >> >> - Config de la Perc -> Perc cache enable et disk cache enable >> >> Ludo. >> >> >>> Le 14/10/2021 à 12:18, Frédéric Dumas a écrit : >>> Bonjour, >>> >>> que ce soit par la console locale avec la commande cp, ou par le client vSphere, le backup manuel de VMs entre datastore locaux se fait à un débit ridicule de 10~12Mo/s. Je m’attendais à 10 fois mieux. Coté hardware, le serveur est un Dell R710, la source est une grappe raid5 branchée au contrôleur PERC H700, la cible un HDD 7200 rpm, branché sur un port SATA interne de la carte mère. Remplacer le HDD par un SSD n’a rien amélioré. Coté software, tous les volumes impliqués sont en vmfs et VMware est en version 5.5. >>> >>> Ce genre de transfert lent rappelle-t-il des souvenirs à certains, qui pourraient m’aiguiller ? Est-ce une limite hardware voulue par Dell (le HDD et le SSD ont des firmwares constructeur génériques) ? Ou est-ce un mauvais usage de la commande copy? >>> >>> Il y a quelques téra à récupérer. Le plus simple serait de laisser tourner le backup quelques jours, mais sur le bureau, le serveur fait un boucan pas possible. Je n’ose pas trop lui retirer les ventilos capot ouvert, les radiateurs des procs sont quand même bien chauds. >>> >>> Si certains ont une piste! Merci. >>> >>> -- >>> Frédéric Dumas >>> f.dumas(a)ellis.siteparc.fr >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Liste de diffusion du FRsAG >>> http://www.frsag.org/ >> -- >> ------------------------------------------------------------------------------------------------------------------------- >> Ce message inclut une signature numérique. Il certifie que l'expéditeur et le contenue du message sont authentiques. >> Si votre logiciel de messagerie est compatible, Il doit garantir que le document n'a pas été altéré entre l'instant où >> l'auteur l'a signé et le moment où le lecteur le consulte. >> Loi n°2000-230 du 13 mars 2000 Art. 1316, 1316-1, 1316-2, 1316-3, 1316-4 du Code civil. >> La présence d'un fichier joint 'smime.p7s' (fichier signature) indique que votre client messagerie n'est pas compatible. >> ------------------------------------------------------------------------------------------------------------------------- >> >> _______________________________________________ >> Liste de diffusion du FRsAG >> http://www.frsag.org/ -- ------------------------------------------------------------------------------------------------------------------------- Ce message inclut une signature numérique. Il certifie que l'expéditeur et le contenue du message sont authentiques. Si votre logiciel de messagerie est compatible, Il doit garantir que le document n'a pas été altéré entre l'instant où l'auteur l'a signé et le moment où le lecteur le consulte. Loi n°2000-230 du 13 mars 2000 Art. 1316, 1316-1, 1316-2, 1316-3, 1316-4 du Code civil. La présence d'un fichier joint 'smime.p7s' (fichier signature) indique que votre client messagerie n'est pas compatible. -------------------------------------------------------------------------------------------------------------------------

3 3

Récupération de données sur un disque dur
by Vincent-Xavier JUMEL 10 Nov '21

10 Nov '21

Bonsoir, Je sais bien que normalement on a des sauvegardes de tout, mais bon parfois, on a été pris par un peu de procrastination (et un peu de faute à pas de chance aussi). Bref ! Connaitriez-vous une boite qui fasse de la récupération de données sur disque dur endommagé ? Proche Paris de préférence. D'avance merci. -- Vincent-Xavier JUMEL Id: 0xBC8C2BAB14ABB3F2 https://blog.thetys-retz.net Société Libre, Logiciel Libre http://www.april.org/adherer Parinux, logiciel libre à Paris : http://www.parinux.org

8 7

Dégradation perfs Linux sur le long-terme
by David Ponzone 08 Nov '21

08 Nov '21

Tous, Je me demandais s’il y avait des valeurs/metrics vicieux/obscurs auxquels il fallait prêter attention quand on tente de déterminer si un Linux a un uptime qui commence à être élevé (plusieurs années). Quand on a fait le tour des indicateurs standards, comment savoir si des problèmes qu’on a pourrait venir de là, et que donc un reboot serait utile (parce que n’étant pas de culture Windows, le ressort au reboot pour essayer au cas où de régler un problème, c’est pas mon délire). Merci

13 14

Apéro Lyonnais : lundi 08 novembre 2021
by cam.lafit 08 Nov '21

08 Nov '21

Bonjour tout le monde Semaine dernière c'était férié alors c'est bien ce soir pour un apéro lyonnais et ses environs ce soir au : Malting-Pot 263 Grande Rue de la Guillotiere, 69007 soit le lundi 08 novembre 2021 dès 19h. Et toujours vaguement des infos sur : http://www.agendadulibre.org/tags/araas https://www.meetup.com/fr-FR/Auvergne-Rhone-Alpes-Apero-Admin-Sys/ Km PS suite à proposition il est possible que nous changions de lieu pour le mois prochain, en fait ce sera un peu plus tard je n'ai pas eu le temps de m'en occuper.

1 0

Re: [FRsAG] Dégradation perfs Linux sur le long-terme
by Pierre Colombier 05 Nov '21

05 Nov '21

Pour ma part, j'ai très peur des machines à gros uptime et qui cumulent un certain nombre de mises à jour (dont on à perdu le compte au fil des mois voir des ans) sans avoir redémarré. Le jour où on fini par le faire, il faut quand même croiser un max de doigts pour que tout se passe comme espéré. On 04/11/2021 10:35, Thomas Constans via FRsAG wrote: > Ah les concours de ziz... ^w d'uptime, c'est moche > > Perso je reboote tous mes serveurs 1 à 2 fois par an) : > > * je suis sur que toutes mes applis utilisent bien les dernières lib > à jour > * je suis sur que mon système tourne sur le dernier noyal à jour > * je suis sur que mon système et ses services redémarrent sans pb > * les applis qui bouffent de la ram petit à petit rentrent dans le > rang. > > >

2 1

Re: [FRsAG] Git et image de filesystem
by Pierre Colombier 05 Nov '21

05 Nov '21

J'ai réussi avec mtree Mais je garde getfacl/setfaclen réserve. Note: En fait c'est vraiment bourrin mon truc... Le commit initial à 80k fichiers, faut surtout pas avoir une gui qui tente de t'afficher le diff. On 25/10/2021 16:42, Fabien GAUTREAU wrote: > Bonjour, > > Il existe le couple getfacl/setfacl > > A voir si cela te convient > > Fabien > > Le 2021-10-25 11:04, Pierre Colombier via FRsAG a écrit : >> Bonjour, >> >> J'ai un filesystem (ext4) que j'aimerai intégralement versionner dans >> un dépot Git. >> >> >> Problème : git ne gère pas les propriétaires/groupes ni la plupart des >> droits d'accès. >> >> Existe-il une façon classique de conserver ces métadonnées et de les >> réappliquer ? >> >> >> >> >> _______________________________________________ >> Liste de diffusion du FRsAG >> http://www.frsag.org/

1 0

Re: [FRsAG] Git et image de filesystem
by Pierre Colombier 05 Nov '21

05 Nov '21

A propos de dd, Je ne veux pas versionner l'image mais les fichiers qui sont dedans. L'idée est d'ensuite utiliser le CI/CD de gitlab pour régénérer l'image de la clé amorçable. Pour ce qui est de versionner les scripts qui permettent de la bâtir, oui c'est bien aussi. C'est beaucoup moins bourrin en tout cas. Mais c'est aussi beaucoup plus compliqué parce que justement, il faut scripter l'install, et que certaines opérations sont faites par des logiciels qui ne sont pas conçu pour être non-interactif. On 25/10/2021 16:04, Affichage cfgi wrote: > Bonsoir, > > Pourquoi pas un dd. > Je génère mes clefs amorçables avec ça. > > --- > Bernard BELLE - C.F.G.I. > ---------------------------------- > Envoyé depuis mon AMSTRAD CPC 6128 > ---------------------------------- > > Le 2021-10-25 15:00, frsag(a)thomas.cuivre.fr.eu.org a écrit : >> Le 25/10/2021 à 12:39, Pierre Colombier a écrit : >>> >>> Précision sur le/les cas d'usage >>> >>> >>> Le filesystem est un os "embarqué" d'environ 200Mo qui se pose une >>> une mémoire flash du genre sdcard ou clé usb ou plus probablement >>> flash directement soudée sur la carte. >>> >>> On l'y uploadera sous la forme d'une image brute. >>> >>> >> Dans ce cas une autre option possible, plutôt que de versionner >> l'ensemble de l'image, serait de versionner les scripts qui permettent >> de la bâtir (par exemple une recette Yocto). >> _______________________________________________ >> Liste de diffusion du FRsAG >> http://www.frsag.org/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

FRsAG