NSA: Please Turn off the Lights When You Leave. Nothing to See Here.

Linux Advocate Dietrich Schmitz shows how the general public can take action to truly protect their privacy using GnuPG with Evolution email. Read the details.

Mailvelope for Chrome: PGP Encrypted Email Made Easy

Linux Advocate Dietrich Schmitz officially endorses what he deems is a truly secure, easy to use PGP email encryption program. Read the details.

Step off Microsoft's License Treadmill to FOSS Linux

Linux Advocate Dietrich Schmitz reminds CIOs that XP Desktops destined for MS end of life support can be reprovisioned with FOSS Linux to run like brand new. Read how.

Bitcoin is NOT Money -- it's a Commodity

Linux Advocate shares news that the U.S. Treasury will treat Bitcoin as a Commodity 'Investment'. Read the details.

Google Drive Gets a Failing Grade on Privacy Protection

Linux Advocate Dietrich Schmitz puts out a public service privacy warning. Google Drive gets a failing grade on protecting your privacy.

Email: A Fundamentally Broken System

Email needs an overhaul. Privacy must be integrated.

Opinion

Cookie Cutter Distros Don't Cut It

Opinion

The 'Linux Inside' Stigma - It's real and it's a problem.

U.S. Patent and Trademark Office Turn a Deaf Ear

Linux Advocate Dietrich Schmitz reminds readers of a long ago failed petition by Mathematician Prof. Donald Knuth for stopping issuance of Software Patents.

Showing posts with label Cgroups. Show all posts
Showing posts with label Cgroups. Show all posts

Friday, May 10, 2013

cgroups: A BIG WIN for Systemd

by Dietrich Schmitz

Oh dear.  What have I done?  :/


I am afraid I have stirred up a hornets nest.  With several related articles under my belt regarding systemd, I continue to pursue this subject matter because of its great importance.

As an advocate, it is important to be critical.  It is also important to turn things over and see things in as objective thinking as is possible, looking for the merit. (Image credit: Red Hat)

Today, I focus on some of the merit that has many so enthusiastic about systemd.

In particular, cgroups, a new technology in the Linux Kernel has been integrated into systemd.

What Matters to System Administrators and Users?


The truth is, most users won't even see or give a hoot about cgroups or systemd, nor will they care anything about their Distro other than how they use it for every day things.  And that is to be expected.

But to the Linux System Administrator who must keep servers numbering in the hundreds or more stable and running without interruption, the devil is in the details and necessarily they must know and understand systemd to accomplish routine configuration changes and to respond to situations that require attention such as when a daemon service becomes unresponsive and must be bounced (stop/start).  These kinds of things are what System Administrators do and the process of learning new technology is a necessary ingredient to staying on the cutting edge and maintaining proficiency.

So, I've spent considerable time poking at systemd, yes?  This time I look at why, just why, maybe there is merit in employing systemd.  Now, many of you are ready to take issue with me, but please remember my role here.  Advocacy is 'for' and 'against' so I've been most often against certain things.  Putting aside how systemd was designed (merging udev) and what that did to the larger Distro community, cgroups does indeed offer something quite good.


The Return of the Zombies


You see it often.  A 'Zombie' child process or an unresponsive daemon service requires your attention.  It is a source of continual maintenance when a service goes silent or one of its child processes does and the whole daemon service shuts down randomly with no explanation.  System Administrators say: "It just happens now and then, that's why we run Nagios to stay on top of it."

That's fine and tools like Big Brother and Nagios are what is needed in this context.  But does systemd offer a finer degree of control given that it has croups embedded?

The answer is yes.

cgroups and Why They are Important

To the extent that Red Hat has a vested interest in the furtherance of systemd and plan to deploy such technology in their next iteration of Red Hat Enterprise Linux 7, much, if not all, of the work being done thus far on systemd has been undertaken by one of their employees +Lennart Poettering.  To his credit, Lennart has been around the corner, so to speak, and has a track record for writing many complicated projects, including PulseAudio.   

So, where can one find more about cgroups?  It just so happens that Red Hat have been doing their own homework, per usual, and have many on-line resource materials that help educate the System Administrator, including some good information about cgroups here.

In the course of discussion in the comment section of my website, one article, stirred the hearts of many to come forward and respond.  One individual has done a good job of giving good constructive replies and demonstrates a better understanding of systemd than perhaps any other respondent I have read.  In my story: Systemd: An Accident Waiting to Happen, Peter Dolding writes:












Shell scripts don't trace processes. This is the problem scripts and items like it work as long as everything is well behaved.

As soon as you get malfuncting service. Solaris zones or linux cgroups around it keeping track of every process it starts. Becomes a good send. 
The problem for over 30 years the same thing:
1) init starts a service process.
2) The service process starts some other sub process it needs.
3) The service process gets terminated to restart
4) The sub process stays running.
5) service started falls over in a heap because sub process is still alive. 
That 1 to 5 (rundown) to your normal init systems includes (Ubuntu's) upstart. 
Solaris and systemd due to usage of zones and cgroups (respectively): 
1) init starts a service process wrapped.
2) The service process starts some other sub process it needs.
3) The service process gets terminated to restart
4) The sub process stays running.
5) Init system checks if anything is left in the cgroup or zone that should have been terminated.
6) service restarted stable.
This is why the old system is broken Dietrich.
Is systemd the right fix needs to be the question--not putting your head in sand and pretending problem does not exist. 
Dietrich the other big thing you have missed is that udev is going into the Linux kernel. As a kernel feature. BSD and other operating systems really have to catch up. 
There are major performance issues running udev userspace. There is also security issues runnign udev userspace. There will be no need for systemd to look after udev long term. Because udev will not exist.
Instead kernel udev will be used.
It's the same kicking and screaming over moving video card memory management into kernel space.
This is nicely put.  I have yet to see anyone explain it better and in such concise terms.  Well done Peter Dolding.


Conclusion


If more people will step back from the issue and wrap their minds around the above, I think it will help them to grasp what is happening to Linux in the long term.  Does breaking compatibility with things related to BSD matter?  I am not sure on that.  Debian chose to make systemd an opt-in choice for their just released Debian 7 Wheezy project, specifically because it does break GNU/kFreeBSD.

I want to believe their is merit in systemd and so, in this round, I am looking at the glass 'half-full' as opposed to being 'half-empty'.  

I pledge to l continue, in investigatory fashion, to examine all things which effect Linux, turning them over to see them from different perspectives.  That is necessary to being a good advocate.

With that, I hope this post has done some good.  What are your thoughts?

-- Dietrich




Enhanced by Zemanta

Wednesday, April 24, 2013

Linux Containers and Why They Matter

by Dietrich Schmitz

Until recently FreeBSD Jails and SUN Solaris Containers were the only other Virtualized Environment (VE) technology players offering such capabilities.  Now, enter the newest kid on the block: Linux Containers (LXC).

LXC is chroot 'on steroids' and lets not only applications run in isolation but also entire operating systems, even raw image virtual machines.  While not true Virtual Machines, these virtual environments, or containers, can run as multiple instances each in full isolation on a single host.

With the advent of a relatively new technology which became available in Linux Kernel 2.6.24, CGroups (short for Control Groups) was devised and allows the host CPU to better partition memory allocation into 'Namespaces'.  CGroups provide the ability to create Linux Containers with isolation, resource limiting, prioritization, accounting, and control.

So, great.  Now Linux has LXC.  Why does this matter?

For one, LXC is not as resource intensive as traditional Virtual Machines (VMs) in that there is no up-front preload of emulation management software.  Thus, the application spawned in a container is running with no added overhead aside from LXC initialization.  The implication is that aside from the small memory software shim, LXC will have bare metal performance characteristics.  The advantages are clear and the deployment is relatively easy.

In terms of disadvantages, and, unlike VMs however, there is no live-migration capability and other sophisticated management console nicities the likes of which vendors Citrix, VMware and Amazon Web Services offer to users of their cloud 'high availability' Infrastructure as a Service (IaaS).  And there aren't (yet) things like AWS Market Place, where one can pick ready-made virtual-machines fully provisioned and just a matter of minutes away from deploying and having up on your subnet.  No, LXC does demand some manual work, but still, it's not so much as to become burdensome.  It is really worth the effort.

Still, LXC is slowly coming into maturity on Linux with feature API inclusion in OpenStack and Stackato IaaS offerings, for example.

Now present in Fedora 18, one can utilize libvirtd-sandbox, so LXC containers can be easily configured as application sandboxes with a high-degree of security and with minimal effort required as compared to setting up a chroot environment or more labor intensive and difficult to manage sandbox solution such as SELinux.

LXC comes with your Linux Distro's kernel for free.  Competing solution OpenVZ requires a special compiled kernel to create its own container solution.

Taking LXC to the next level is seen in a new product called Docker.



As the above Youtube video suggests and as more software developers employ LXC, you'll see more creative ways of wrapping LXC in generic objects such as Python Go programming language based Docker to facilitate even easier flexible configurability and deployment.

So, there it is.  LXC, yet one more great resource for Linux Developers and Systems Administrators to avail themselves to.  Study up!  It won't be a wasted effort.

-- Dietrich
Enhanced by Zemanta