{"id":968,"date":"2011-05-05T19:14:37","date_gmt":"2011-05-05T13:44:37","guid":{"rendered":"http:\/\/judepereira.com\/blog\/?p=968"},"modified":"2011-05-05T19:21:46","modified_gmt":"2011-05-05T13:51:46","slug":"creating-unique-environments-chroot-snapshots-using-aufs2","status":"publish","type":"post","link":"https:\/\/judepereira.com\/blog\/creating-unique-environments-chroot-snapshots-using-aufs2\/","title":{"rendered":"creating unique environments – chroot snapshots – using aufs2"},"content":{"rendered":"

What if you decided that you wanted to experiment and test within a chroot(ed) environment? And then something went wrong and you had to start all over again from scratch? Big headache, too much pain, especially with RPM based distributions.<\/p>\n

Well don’t do that then, here’s an interesting approach. Use aufs2, a stackable filesystem. An actual filesystem with “RAID-like<\/em>” support.<\/p>\n

\"chroot<\/a><\/p>\n

You can inherit different environmental settings from various bases, much like the concept of object oriented programming.<\/p>\n

Aufs is a stackable unification filesystem such as Unionfs, which unifies several directories and provides a merged single directory.<\/strong><\/em>(from http:\/\/aufs.sourceforge.net\/<\/a>)<\/em><\/p><\/blockquote>\n

Setup aufs2. You need to patch your kernel. For gentoo, you can just merge sys-fs\/aufs2 with the following flags: “fuse inotify kernel-patch kernel_linux ramfs -debug -hardened -hfs -nfs”. The patch will be automatically applied, you just need to recompile it after merging. For other distributions, take a look at the homepage of aufs2<\/a>.<\/p>\n

Setup your chroot as you normally do. Let’s say you’ve setup centos in a chroot environment, for developing. You’ve done yum groupinsall “Development Libraries” “Development Tools”. Let’s create a snapshot here of this environment.
\n[sourcecode lang=bash]
\n# mkdir env1
\n# mount -t aufs -o br=\/home\/jude\/env1\/:\/home\/jude\/centos-dev=ro none wor
\nk-dir
\n# chroot work-dir
\n[\/sourcecode]
\n 
\nWhat does this do? As you can see, your first centos-dev has been branched as RO, read-only<\/em>. Which means, any changes now made, are transparently written into env1 directory, with the very same structuring. Say, you’ve structured env1 as you want it to be, now you need a second environment, based on the first env1, you can simple do:
\n[sourcecode lang=bash]
\n# mkdir env2
\n# mount -t aufs -o br=\/home\/jude\/env2\/:\/home\/jude\/env1\/=ro:\/home\/jude\/ce
\nntos-dev=ro none work-dir
\n# chroot work-dir
\n[\/sourcecode]
\n 
\nNow, env1 is RO, any changes now are further written to env2, keeping the structuring of every little change intact, just as the first. If you want to suddenly use env1, don’t add env2 to the RW branch, any branch that doesn’t have anything in front of it, is assumed to be RW, read-write<\/em>.<\/p>\n

What happens when you delete a file\/directory from a branch mounted as RO? A file called .wh.filename is created in the RW branch, indicating to the overlaying filesystem to NOT<\/strong> index that file anymore.<\/p>\n

In this way, you could create several different environments, each being inheriting a base, and then depending on the needs, the other environments created.<\/p>\n

You can comment if you get any errors, I’d be glad to help you out.<\/small><\/em><\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

What if you decided that you wanted to experiment and test within a chroot(ed) environment? And then something went wrong and you had to start all over again from scratch? Big headache, too much pain, especially with RPM based distributions. Well don’t do that then, here’s an interesting approach. Use aufs2, a stackable filesystem. An […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[11,10],"tags":[209,211,210,217,220,219,221,214,215,218,226,212,213,222,224,225,223,216],"class_list":["post-968","post","type-post","status-publish","format-standard","hentry","category-gen-sab-fed","category-linux","tag-aufs","tag-aufs-usage","tag-aufs2","tag-chroot","tag-chroot-dev","tag-chroot-devel","tag-chroot-developer","tag-chroot-different-env","tag-chroot-environment","tag-chroot-linux","tag-chroot-rpm-dev","tag-chroot-secure","tag-chroot-snapshot","tag-chroot-testing","tag-chroot-unstable","tag-chroot-user","tag-chroot-work","tag-config-environment"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t