Il arrive que l'usage du disque soit différent de la taille des objets qui l'occupent et ce pour diverses raisons : "trous" dans les fichiers, fragmentation, blocs non contigus..

Pour afficher la taille apparente, utiliser l'option --apparent-size
"""
--apparent-size
print apparent sizes, rather than disk usage; although the apparent size is usually smaller, it may be larger due to holes in ('sparse') files, internal fragmentation, indirect blocks, and the like
"""

Analyser les appels systèmes d'un programme pour trouver la cause d'un problème (ou à des fins de compréhension / reverse-engineering), avec strace donc.

et sinon, pensez à utiliser sysdig, son clone sous hormones: https://jeekajoo.eu/links/?Z0A7gg

"""
psDooM is a process monitor and manager for *nix systems. It could be considered a graphical interface to the 'ps', 'renice', and 'kill' commands. psDooM is based on XDoom, which is based on id Software's 'Doom'.
"""
Chaque personnage est associé à un process unix.
Le tuer revient à faire un kill -9 dessus.

Je pense que si tu tues le PID 1 t'as perdu (ou gagné. Ca dépend comment tu vois les choses). ;)

Screenshots: http://psdoom.sourceforge.net/screenshots.html

EDIT: haha sourceforge.net appartient maintenant à la blacklist "Badware risks" qui est notamment utilisée par uBlock origin.

parfois c'est juste du bon sens, pas du #BOFH (https://en.wikipedia.org/wiki/Bastard_Operator_From_Hell)

WANTED: Admin Sys

3 ans d'XP minimum avec l'utilisation d'un outil de gestion de configuration, parce qu'on fait que de l'infra as code avec saltstack, sur ec2.

"""
Now you can resize InnoDB buffer pool online. Since MySQL 5.7 innodb_buffer_pool_size is a dynamic variable which provides the ability to resize buffer pool without restarting MySQL server.
"""
yaisse! #sysadmin

Une présentation culte qui parle des postes de "DevOp" en entreprise.

Même si je pense qu'un poste de "DevOp" ça n'a pas de sens (https://jeekajoo.eu/links/?hD9S7Q) du point de vue de mon xp actuelle, l'auteur pense le contraire et explique le rôle que doit avoir ce DevOp.

"""
Slide 73: ownership over the TOOLS to improve DevOps efforts.
"""

On ne parle pas de l'infra ici dont la responsabilité est laissée aux sysadmins.
Bonne approche.

Haha, j'aurais été tenté de répondre comme toi, Kevin (http://www.mypersonnaldata.eu/shaarli/?oBPM7A), mais en fait non. Je vais argumenter.
Le sysadmin code aussi, mais il ne fait pas que ça.

Il code car il doit créer l'infrastructure qu'il souhaite la plus jetable possible. Le but c'est d'être capable de recréer toute l'infrastructure from scratch depuis son code. C'est ce qu'on appele l'infrastructure as code. TOUT est code, de la taille des machines à leur nombre de disque en passant par les règles firewall et les membres d'un loadbalancer. Cette infra est le plus souvent écrite dans un DSL propre au logiciel de gestion de configuration utilisé.
Pour Saltstack, c'est majoritairement du yaml qui décrit l'état des services (states). On retrouve du jinja pour la partie templating et pour ajouter un peu de logique dans les states. On peut également avoir besoin de faire du python pour développer des modules spécifiques.

Enfin de manière générale, on utilise beaucoup python et bash pour l'administration, le monitoring ou pour des tâches lancées via cron sur les serveurs.

Le problème c'est que peu de monde comprend le métier de sysadmin (ou Ops comme ils disent aux states). Mêmes certains devs ignorent ce qu'on fait au jour le jour. Est-ce qu'on peut dire que ce sont de mauvais dev? Peut-être mais la direction d'une entreprise a d'abord un vrai rôle à jouer pour que tout ce petit monde coopère et puisse bosser ensemble.

La réalité c'est que le métier de sysadmin n'est pas mis en valeur car leur produit, l'infrastructure, n'est pas directement "visible". On ne pense aux sysadmins que quand le service tombe ou quand celui-ci est lent. Et c'est justement tout l'enjeu de notre métier que cela ne se produise jamais.

On parle de "DevOps"[1] pour justement améliorer la communication entre les équipes, qu'on arrête de considérer les sysadmins comme des larbins et pour que la communication se fasse dans les 2 sens. Car les sysadmins sont avant tout des architectes. Des architectes ayant l'expérience de la montée en charge, de savoir quel RDBMS il est préférable d'utiliser plutôt qu'un autre, de connaître le comportement d'un redis en production, de savoir sur quels axes on pourrait améliorer les performances d'une application, etc.. Bref, au même titre que les developpeurs, les sysadmins doivent être impliqués le plus tôt possible dans les choix techniques.

[1] Le problème de ce mot "DevOps", c'est qu'il est galvaudé. Certains chasseurs de tête l'utilisent pour désigner des titres de poste alors qu'il ne s'agit que d'un état d'esprit. Un état d'esprit visant à dire que moi developpeur je ne connais pas tout ; alors je vais aller poser des questions aux sysadmins. Et inversement.

En marge de la vulnérabilité sur bash (et de la connerie d'utiliser du cgi en 2014 + avoir un user www-data dont le shell est capable de se logguer...), il y a celle de Xen.

Cette faille n'a pas encore été révélée publiquement. Il faudra attendre le 1er octobre pour qu'elle le soit. C'est pour laisser le temps à des acteurs comme amazon oracle citrix rackspace etc.. de patcher. voir pre-disclosure list complète: http://www.xenproject.org/security-policy.html

Il y a fort à parier qu'il s'agit là d'une très grosse faille que amazon ne souhaite pas laisser être exploitée. Ils ont donc pris la décision de patcher tous leurs hyperviseurs avant le 'disclosure'.

Les conséquences pour les clients, dont l'entreprise pour laquelle je bosse, sont désastreuses ; car il s'agit de redémarrer - sous 3 jours! - un nombre conséquents de serveurs. Même en redémarrant préventivement des vm, on est pas sur qu'elles arrivent sur un hyperviseur qui est patché ; et donc elles redémarreront suivant la maintenance qu'aura prévu Amazon (ce week-end pour ma boite)... Bref, grosse galère, surtout pour les serveurs dont les données sont sur des stockages éphémères..

Enfin pour ce qui est de la faculté pour amazon de faire de la migration live, je rejoins ce commentaire:
"""
I would be surprised if Amazon didn't have high availability and live migration in the background, allowing them to reboot individual hypervisor hosts. You would still be stuck in your pool, but then if a host dies/needs patching it doesn't affect the guest VMs.

My suspicion is that the patch requires updating paravirtualization drivers (xen tools), which run on the VM itself and thus might require a reboot to update.
"""

Cette vidéo montrent 2 netadmins allemands qui découvrent 'en direct' que le GCHQ a infiltré le FAI (Stellar PCS) pour lequel ils travaillent.
Stellar PCS est un FAI spécialisé dans la fourniture d'accès internet via satellite pour des régions du monde qui ne disposent pas des infrastructures nécessaires.

Vidéo tirée de https://firstlook.org/theintercept/2014/09/14/nsa-stellar/

rhooo, pas à ce point ké même
via https://twitter.com/nixcraft/status/502055910114488320/photo/1

joyeux "sysadmin day"

je connaissais 'ccze' mais pas 'colout'.
exemples et screenshots: http://nojhan.github.io/colout/