I'm going to answer this question as wholly and honestly as I possibly can. Nevertheless, I have filled this answer with an occasional shameless plug. You've been warned.

For starters, I work at www.bazaarvoice.com | Bazaarvoice. We're big fans of cloud. Real big. We're also fans of DevOps. There's a lot of discussion these days about "What is DevOps?" Usually, this term is used to describe Systems Programmers (sometimes called Infrastructure Engineers, Systems Engineers, Operations Engineers or, in the most unfortunate case, Systems Administrators). This is not what DevOps means, but in the context of career development, it carries the connotation of a "modern" Systems Programmer.

So, you're a developer and you want to get in on the ops action. Boy, are you in for a surprise. This isn't about installing Arch Linux and learning to write Perl. There's a place for that kind of thing (a very small, dark place in a very distant corner of the universe), but let's first consider a few things about what DevOps is and what DevOps is not.

What a DevOps role is:

Writing code / software.
Building tools.
Doing the painful things, as often as you can.
Being on the on-call rotation for 2 a.m. production outages.
Infrastructure design.
*NIX. Because Windows freaking sucks. (That said, I use OS X and prefer it to any *NIX distribution, but under the hood, it's *NIX, too.)
Scaling stuff. Scale matters.
Maintenance. Like rebooting that frail vhost with a memory leak that no one's bothered to fix or take ownership of.
Monitoring. Lots of it.
Virtualization.
Agile development methodology.
Software release cycles and management.
Automation. Automation. Automation.
Designing a branch/release strategy for the provided SCM (git, Mercurial, svn, etc).
Metrics / reporting. Goes hand-in-hand with monitoring.
Optimization / tuning.
Load / performance testing and benchmarking, including performance testing of highly complex systems.
Cloud. Really, you don't have to have cloud experience, but it can fundamentally change the way you think about complex systems.
Configuration management. (You've surely heard of Puppet, Chef, Ansible, etc. Yes?)
Security.
Load balancing / proxying. (Of services, systems, components and processes.)
Authentication services.
Command-line fu (like

awk

.
Package management. Freaking package management.
CI/CIT/CD -- continuous integration, continuous integration testing, and continuous deployment. This is the closest thing to the real meaning of "DevOps" that a Systems Programmer will do.
Databases. All of them. SQL, NoSQL, whatever.
Solid systems expertise. We're talking about the networking stack, how hard disks work, how filesystems work, how system memory works, how CPU's work, and how all these things come together. This is the traditional "operations" expertise you've heard about.

What a DevOps role is not:

Easier than being a software engineer.
Never writing code. I write tons of code.
Installing Linux and never touching your favorite OS again.
Working the third shift. (At least, it shouldn't be; if it is, quit your job and come work with me: Keep Austin Bazaar.)
More "fun" than being a software engineer.
Greenfield. You'll deal with old stuff in addition to new stuff.

La raison pour laquelle on voit des block en OUPUT de certains type ICMP dans les scripts iptables :

Scanning for open UDP ports is done with the -sU option. With this scan type, Nmap sends 0-byte UDP packets to each target port on the victim. Receipt of an ICMP Port Unreachable message signifies the port is closed, otherwise it is assumed open.

One major problem with this technique is that, when a firewall blocks outgoing ICMP Port Unreachable messages, the port will appear open. These false-positives are hard to distinguish from real open ports.

Pour cancel un commit qui n'a pas encore été push

git reset --soft HEAD^

truestory :

Let’s not build that feature.
Is there existing software that could be used instead?
Let’s not add this functionality.
Does the complexity it will introduce really justify its existence?
Let’s not build that product yet.
Can we first do some small things to test the assumption that it will be valuable?
Let’s not build/deploy that development tool.
Can we adjust our process or practices instead to make it unnecessary?
Let’s not adopt this new technology.
Can we achieve the same thing with a technology that the team is already using and familiar with? “The best tool for the job” is a very dangerous phrase.
Let’s not keep maintaining this feature.
What is blocking us from deleting this code?
Let’s not automate this.
Can we find a way to not need to do it all?

ça a l'air chouette, dommage que la version soit limitée à un kernel si vieux et que ce soit seulement packagé en rpm

à tester quand même sur une centos 6.5

Chez OVH une boite mail et un petit espace d'hébergement est offert quand on loue un domaine.

Pour l'activer il faut se rendre dans le manager, cliquer sur le domaine en question dans la liste des Domaines à gauche
Puis à droite "Activer un hébergement web" (choisir le Start10M Gratuit)
Il faut ensuite valider la commande et attendre que l'opération se termine

Ensuite dans la colonne à gauche, dans la section email, cliquer sur le domaine concerné et là miracle on peut créer une boite mail et un grand nombre d'alias et la possibilité de rediriger..

Pratique pour recevoir des mails sur un domaine custom sans se prendre la tête

Plus d'info : https://www.ovh.com/fr/domaines/offre_hebergement_start10m.xml

sleep $(shuf -i 1-600 -n 1) && /bin/gogo

Via eespie