Mid-Week Neat Trick - With Proper Attribution

Hey there,

I actually have some stuff to write today, and was going to write it, but while I was trying to figure out an issue at work (that, strangely enough, had absolutely nothing to do with the topic of this post ;), I happened upon a great article, regarding novel uses of dd and text-based web tools like curl and wget, over at omnipotent.net's Linux article section

The trick it describes is one you may have heard of before, or put into practice, but I liked the author's enthusiasm for the subject matter (which comes through in the writing - along with many links to other interesting pieces) and thought I'd table my own meandering thoughts for a day and turn you on to someone else's ;)

I've included the introduction below. Follow this link, or the link at the end of this section, to continue reading. In fact, just click the link. All the really cool stuff follows the opener, although it sets up the mood quite nicely :)

Enjoy and cheers,

---

Surprisingly, I got quite a bit of response from my last piece, "Stupid Linux Tricks." That article was something I'd dashed off at the last second because I hadn't thought of anything provocative or rant-worthy to write about. Still, it seems to have hit an interesting chord with quite a few people. The idea that the best way to convert a person is to demonstrate some of the incredibly cool, useful, or just plain well-designed stuff about Linux. So, since I'm out of ideas this week too, I'll do something similar -- but instead concentrating on some of the smaller tools and what they can do. 
Let's face it: Unix isn't a single, large product -- it's a fantastically modular system. It's so modular, in fact, that every component can in theory be replaced! So much so, that there is no single part of the Unix architecture that can, strictly speaking, be called Unix. The Linux kernel is just an implementation of an API, and an abstraction layer for hardware. That's not Unix. Neither are any of the potentially thousands of programs that make up Solaris, Linux, BSD, or any of the other ones. Any individual component is trivial, and is a part of a larger, cohesive whole. 

Within that collective framework of tools, the user learns how to take advantage of them, one by one, learning how they interact and lock together, and their purposes and use. Often, a tool is used for purposes very unlike its intent. Almost frighteningly so, in fact. Very impressively so. Showing someone what these tools, few of which work as well as eye candy, can do to make your life easier is how you "clinch the sale" so to speak. So what if Linux can do all these cool things to impress people? Now you have to show them what it can do to make their lives easier in some small way... CONTINUE READING...

---

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

A Nice Linux ScreenSaver

Hey there,

Well, now that the sickness is abating, I'm back to working on the weekend ;)

Hope you enjoy this cool little screensaver script I found over at BloggEd

I included the basic code below, but you should check out the site for a good write-up and instruction on how to use and modify it for your system's kernel.

Enjoy :)

---

#!/bin/sh

file=phosphor-kernel-src.pl     # script to create
linux_src_dir=/usr/src/linux    # location of kernel src

cat << EOF > "$file"
#!/usr/bin/perl
srand;
rand(\$.) < 1 && (\$line = \$_) while <DATA>;
print \$line;
__DATA__
EOF
find -L "$linux_src_dir" -name \*.c >> $file
chmod 555 $file

---

, Mike

---

Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

The F Word Still Remains - More Linux And Unix Humor

Happy Saturday,

For this weekend's Linux and Unix humor kick-off, I'm going back a ways to a piece I half-hesitate to touch because I don't want the Moral Majority slapping "Content Warning" stickers on this blog. Still it's funny and interesting, so funk 'em (this trick is used by many rock bands and the FCC is okay with it, so I think I'm on solid ground using it in place of the other f word ;)

The piece below is from Sean Dreilinger's Web Page under the heading of the Linux Kernel Fact Center. This original page also includes a link to another citizen who's carrying the torch over at Vidarholen.net. A few interesting graphs there, too, like the one below (not actually "taken" from his page, but linked back to with an "img src" tag).

Also, just for yucks, I gave this a shot on a Linux box (SUSE 8) from work which indicates that even folks who write for a proprietary Linux OS manage to slip one by now and again ;) ...sanitized version...

host:~ # uname -a
Linux host 2.4.21-251-smp #1 SMP Thu Sep 23 17:22:54 UTC 2004 i686 unknown
host:~ # find /usr/include|xargs grep -i f###
/usr/include/linux/netfilter_ipv4/ipt_limit.h:  /* Ugly, ugly f###er. */
/usr/include/linux/netfilter_ipv6/ip6t_limit.h: /* Ugly, ugly f###er. */

Hope you enjoy the article and be sure to visit The Linux Kernel Fact Center for more of the same, and some other different stuff :)

Cheers,

---

Linux Kernel F Count

in 1998, glenn forwarded me a message from the linux kernel hackers
list. this message suggests that the linux
kernel source is laden with profanity, the word f### in
particular. my curiosity led me to untar, grep, and
wc through a selection of linux kernels, in search of
love, f###, and some other trends in the evolution of linux.




it would appear to be pretty difficult to get a linux
kernel hacker to swear (or express any form of love---lovable,
lovably, love, loved, lovelier, lovelies, loveliest, loveliness,
lovelorn, lovely, lover, lovers, loves, loving, lovingly, etc.)
in the linux kernel source. from the chart below you have to wonder
what was going on around kernel 2.1.50 :-).



after the cuss-word novelty wears off, some of the other information is pretty interesting --
such as the the gradual increase in source tree size, file,
line and word counts with each new kernel over the past
six-seven years. i wonder how this sort of growth compares to the
evolution of a commercial operating system kernel.



when you put it all together and
consider that in the present
kernel source, 275 credited kernel authors wrote over 1,895,964 lines of
code and documentation (6,856,723 words) and only managed to cuss 29 times
-- it would seem that these developers show incredible self restraint when
expressing frustration, are complete professionals, are sedated, or are just
enjoying what they do!



update 2006-11-01: thanks for digging this
document; a modern-day continuation of this novelty is maintained by vidar
holen.

---

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Using Grub To Change RedHat Linux's Root Password

Hey There,

I'm back from the dead and no longer cursing Vista ( I've always thought it was strange that most people, including myself, feel disappointment or sorrow when they lose something they didn't have in the first place. The opposite seems perfectly logical. I feel very relieved that I no longer have something that I never had before ;)

Today, we're going to take a look at a quick way to get back your root password (assuming its yours) if, for some reason, you get locked out of your machine. It happens... more than I'd care to admit ;) The course of action I see followed most often is booting from CD, temporarily mounting the physical root drive, and editing /etc/passwd. This is a time-tested solution, and works on pretty much any version of Linux or Unix I've worked with, but I think this way is more fun (and slightly less dangerous). Plus, it saves you a little time (not a lot; just a little). We haven't taken a look at grub since our post on recovering failed raid disks, so I guess this post is about due.

The trick in question has only been tested on RedHat Linux ES, so I can't speak for whether it works on, say, CentOS or Fedora (although I imagine it would work on any system that uses grub for boot loading). Basically, what we're going to do is use grub's boot options to allow us to obtain root access. And, if your machine is properly secured (the /boot directory in particular), you shouldn't be able to edit /etc/grub.conf as a normal user, so physical access (or console/ALOM-type access) to the machine in question is required. It's a pretty simple procedure and goes something like the following:

1. Login to the console on the machine and type "reboot" or "shutdown -r," etc, if you have an account with privileges to initiate such an action. If you don't have an account with suitable privilege, try control-alt-delete (and power off) or hard power-down your machine (you may need to fsck later, but that's a given), take a deep breath and count to 11 ;)

2. Power on the server and wait for the grub boot screen to come up. You'll may not need the GUI for this to work, but it's the only way I've done it. When the grub boot menu comes up, hit the up or down arrow key at least once to stop the automatic boot countdown timer. If you have multiple boot options, choose the one you know (or believe) is the one currently in use (actually, this shouldn't matter, but loading up an older kernel might cause issues) and press the "e" key to enter edit mode.

3. After you enter edit mode, you'll be presented with a few lines of text (dependent on how you have your grub.conf populated). Using your arrow key again, navigate to the line that starts with "kernel." Press the "e" key again, and your cursor should show up at the end of the "kernel" line (if it doesn't, you can move it to where you need it by using the left and/or right arrow keys as necessary).

4. Now that you're in edit mode, and your cursor is in the correct position, type a "space" character followed by "single." So if your boot command line was:

kernel /boot/vmlinuz-2.6.9-34.ELsmp ro root=/dev/sda1
it would now be:
kernel /boot/vmlinuz-2.6.9-34.ELsmp ro root=/dev/sda1 single

5. Now type "b" to continue the boot process and you'll be dumped into a limited shell, as root, passwordlessly. Sometimes this has seemed not to work for me if I changed my edit-focus to a line other than the "kernel" line before typing "b", but that could just be superstition on my part. Thankfully, I don't have to do this all that often :)

6. The rest is gravy. You're root, so all you have to do is type "passwd", set the root password to whatever you like and reboot using your preferred method (reboot, shutdown -r, init 6, whatever works, etc). Since you're in a single-user shell, you can also instantiate a reboot by just typing "exit."
And you should be all set. Now you no longer have an excuse to avoid fixing problems on that machine (the downside ;)
Cheers,

, Mike

---

08/06/2008 - Thanks for this Additional Useful Information From zcat:

On many distros the 'single' or 'rescue' boot will still ask for a
password. You can get around this by starting linux without starting
initd, just launch a shell instead; and it's blindingly fast.

'e' to edit the boot entry, select the kernel line and press 'e'
again, then type "init=/bin/bash", enter, press 'b' to boot it. You
end up at a root prompt with / mounted read-only. (depending on the
distro, you might need /bin/sh instead)

# mount / -o remount,rw
# passwd
<change your root password here>
# mount / -o remount,ro
<three-finger salute or hit the reset button>


It's also useful for fixing up boot problems, if you're silly enough
to have put commands in various init scripts that don't actually exit
or daemonize...

---

Thanks for these comments from Laurent regarding an alternate way to get to single user:

Nice to see that method that I was used to apply. Especially with some servers that have been hardened with password aging implementation. And when it is stable you don't need to log on for more than 60 days sometimes....

You could also add that grub can (should?) be password protected.

Cheers

Laurent

Using Sysctl To Change Kernel Tunables On Linux

Hey again,

After correcting a few of the train-wreck sentences I wrote for yesterday's post (note to self: must not think while typing ;) I figured I'd flip 180 degrees and move on to the subject of modifying kernel tunable parameters on Linux (specifically tested on RedHat) using sysctl. For the Solaris enthusiast out there (who hasn't worked with Linux all that much) /etc/sysctl.conf on RedHat Linux can be thought of as a rough equivalent of /etc/system on Solaris (The last time we came close to trying to draw a comparison between these two files was back in May in a post regarding safe patching of a Veritas root disk). The sysctl command on Linux doesn't translate quite so well to some older versions of Solaris (some things could be done with ndd, but less of some and more of the other - a vague resemblance at best). Newer versions of Solaris that make use of the "project" based configuration are more directly relatable (projadd, projdel, projmod and projects are four commands that all modify, or report on, kernel tunables on-the-fly like sysctl can, although they make use of a completely separate configuration file - /etc/project - to store values), but I digress... (After yesterday's train wreck sentences we have a run-on... coincidence? :)

As noted, sysctl is a very versatile command and can be used either in its standalone form, or through the modification of the /etc/sysctl.conf file. First, we'll take a brief look at what the sysctl standalone command can do. It doesn't have too many options, so explaining them quickly upfront will make the rest seem like it makes more sense ;) You can run sysctl with the following flags (maybe more, depending on your distro):

-a to display all the tunable key values currently available
-A to display all the tunable key values currently available, as well as table values
-e to ignore errors (specifically pertaining to unrecognized characters)
-n to "not" print the key names when printing out values
-N to "only" print the key names and forgo printing their values
-p (sometimes -P) to import and apply settings from a specified file. This option will use /etc/sysctl.conf as the default if no file name argument is provided on the command line
-q for your standard quiet mode
-w to change kernel tunable (sysctl) settings - This will make the change in real time, as well as update the /etc/sysctl.conf file

and two more "special" arguments:

variablename <-- Use this on its own to read a key from sysctl matching your variablename
variablename=value <-- Use this to set a variablename (key) to a specific value. Note that this needs to be used with the -w flag (which changes sysctl settings)

Some basic examples of sysctl's use would include:

host # sysctl -a <-- This will produce a huge list of output. The basic format would be: NAME TYPE CHANGEABLE - with each column's name accurately depicting what it represents. For instance you could get an entry with a NAME of "kernel.hostid" and a TYPE of "u_int" (note that this is the datatype) and a notation on whether or not it's CHANGEABLE - in this instance "yes" The changeable field can also return "no" and "raise only" It seems logical to assume that it could return "lower only" as well, but I've yet to see it.

SPECIAL ERRATA NOTICE: If sysctl -a spews a lot of kernel warnings, check out Advisory RHBA-2008:0020-4 on RedHat's website for a patch to fix that issue.

host # sysctl -p /etc/mytestsysctl.conf <-- this will read in and enact all the kernel changes specified in your special /etc/mytestsysctl.conf file. It's a good idea to use a different filename when testing out new sysctl.conf settings, especially if you're making broad changes, since, if you completely screw the pooch and your machine reboots, it will come back up looking for the default /etc/sysctl.conf which will still be good to go)

host # sysctl -p <-- Use the -p option without any arguments if you've made adjustments to your sysctl.conf file and want to reload it, or just to be sure that it is actually being read (if you have serious doubts, you can run "strace -f /sbin/sysctl -p" to get more granular information. If you find that you do need to use strace to run down a problem with sysctl, hopefully our previous post on using strace to debug application issues will help get you off on the right foot and an expedited solution)

host # sysctl -w kernel.hostname="Error.Dumping.core" <-- this will set the hostname of your machine to something that might possibly be amusing. Please ensure that your superiors (or the folks you work for) have a sense of humor before pulling a stunt like this and walking away ;)

It's interesting, also, to note that, while sysctl will work just fine with an /etc/sysctl.conf file that includes nothing but comments (or is completely non-existent), your /proc filesystem "must" be of the type "procfs" in order for it to function correctly. This is picking a nit, really, since you'd have to go out of your way to build your RedHat Linux box to use (for instance) ext3 for the /proc filesystem, but a bit of information that's good to know (maybe... at some point in the future ;) /proc/sys is the base directory for sysctl. In fact, if you wanted to emulate "sysctl -a", you could just do an ls in that directory.

Tomorrow, or sometime later this week, we'll take a look at some of the kernel tunables you'll probably want to change, or may have to modify, most often with sysctl and, with as even a hand as possible, debate the pro's and con's of some of the more "impactful" values that you can mess with.

Cheers,

, Mike

Installation Security Baselines For Linux and Unix - 1b

Hey there,

Following up on yesterday's beginning of our five part post series on basic Linux and Unix installation security, we're going to complete the initial installation guidelines today. I'll dispense with the fancy rhetoric, and if necessary, apologize for the length of yesterday's post (and today's ;). Although this list is, without a doubt in my mind, incomplete in many ways, I hope that some of you out there find it helpful. If even one suggestion gives you a boost, all this typing is worth it :)

I'll see you on the other side, or when part 2 on user account security comes out tomorrow. Hopefully, given the general connotation of the phrase I just used, it will be the latter ;)

Cheers,

For the initial "default value steps," there are many different default script locations (as well as /etc/xinetd.d), where you can set many of these - through step 25 - on Redhat. I think the most important thing to note is that we're hammering down the umask setting and default paths wherever possible.

20. Set the following values in /etc/default/login (leave all else):

PATH=/bin:/usr/bin
SUPATH=/bin:/usr/bin:/sbin:/usr/sbin
TIMEOUT=300
UMASK=027

21. Set the following value in /etc/default/passwd (check your password policy for setting expiration, etc):

PASSLENGTH=8

22. Set the following values in /etc/default/su (leave all else):

CONSOLE=/dev/console
PATH=/usr/bin:/bin
SUPATH=/usr/bin:/bin:/usr/sbin:/sbin

23. Set the following value in /etc/default/sys-suspend (leave all else):

PERMS=-

24. Create /etc/default/telnetd with the following contents, if this is a box that you own:

BANNER=”\nThis computer is the property of YOURCOMPANYNAME HERE.\nUnauthorized use is expressly forbidden. Violators\nwill be prosecuted to the full extent of the law.\n\n”
UMASK=027

25. Create /etc/default/ftpd with the following contents:

BANNER=”Unauthorized access prohibited”. This will basically be obviated by wu-ftpd (and other, more secure ftp servers), but should be kept in case of any situation which requires you to revert back to the original in.ftpd.
UMASK=027

26. Create /etc/issue (along with /etc/release, /etc/redhat.release, /etc/issue.net and any other issue/release files you may have) with the following contents, if this is a box that you own. The return before the closing double quote is necessary on most systems for the output to format correctly and not bleed into whatever comes next:

“This computer is the property of YOURCOMPANYNAME.
Unauthorized access is expressly forbidden. Violators
will be prosecuted to the full extent of the law.
“

27. cp /etc/issue /etc/motd.

28. Run /etc/security/bsmconv on Solaris. To achieve the same effect on RedHat, add the line "audit=1" to your grub.conf or supply it to grub on the command line. Also, for Redhat, this makes step 29 unnecessary)

29. Add all user accounts on Solaris to /etc/security/audit_user with attributes username:lo:no (NOTE – Please be sure to add and remove users from this file henceforth whenever adding or deleting an account on the system!!!)

30. If possible, within system’s application, add empty .rhosts and hosts.equiv in / and /etc respectively, and chmod 0 and chown root the .rhosts and hosts.equiv files.

31. If possible, within system’s application, add empty .netrc and .exrc files in /. chmod 0 and chown root both.

32. If possible, within system’s application, add empty netrc and exrc files in /etc. chmod 0 and chown root both.

33. Edit /etc/init.d/inetsvc to bring up inetd with –st flags (Use -sd for xinetd). Also, add the following code snippet to the end of inetd's, or xinetd's, init script and disable the specific system auditing user's crontab if possible (On RedHat this may end up in the /etc/cron.* directories). Note that for RedHat, we should use /var/log rather than /var/adm:

if [ ! -d "/var/adm/sa" ]
then
        mkdir /var/adm/sa
fi
chown root:itopsgroup /var/adm/sa
chmod 644 /var/adm/sa/*

34. Uncomment “enable-cache hosts no” line in /etc/nscd.conf. Add “enable-cache passwd no” and “enable-cache group no”, also.

35. If not running Solaris 7 or higher, uncomment savecore in /etc/init.d/sysetup. For RedHat, ensure that you have the diskdumputils RPM installed.

36. Create /etc/ftpusers. Include all accounts except administrators, if possible. Definitely include all generic accounts. Otherwise, it should include root and all system accounts. This will basically be obviated by wu-ftpd (and other more advanced ftp software), but should be kept in case of any situation which requires us to revert back to the original in.ftpd.

37. Create /etc/hosts.allow and /etc/hosts.deny files. If possible, limit the hosts that are allowed to connect by subnet or domain (By IP would be great, but probably impractical). Otherwise, create placeholder files to generate tcpd logging (e.g. ALL:ALL). NOTE: Remove X-11 Forwarding if it is present and you can afford to.

38. Set the following parameters in /etc/profile or /etc/bashrc (add or mix around to suit your needs). Many directories listed are specific to Solaris. Your best judgment on what should be in the default PATH, MANPATH and LD_LIBRARY_PATH variables should be enough to guide you on this part. Everyone's setup is probably different:

PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/etc/vx/bin
umask 027
MANPATH=$MANPATH:/usr/man:/usr/local/man:/usr/share/man:/usr/openwin/man:/usr/dt/man:/opt/VRTSvxvm/man
LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/share/lib:/usr/openwin/lib:/usr/dt/lib
EDITOR=vi
export PATH MANPATH LD_LIBRARY_PATH EDITOR

39. Add administrators group (groupadd –g 666 itopsgroup).

40. Add administrators to the administrators' group.

41. Add additional interface files, if needed, in /etc (e.g. /etc/hostname.hme1 on Solaris or /etc/sysconfig/network-scripts/ifcfg-NICNAME on RedHat).

42. Add two lines containing “set noexec_user_stack=1” and “set noexec_user_stack_log=1” to /etc/system on systems up to and including Solaris version 9. You can still add this in 10, but in later versions of 9, and in 10, this isn't necessary any more. For RedHat, consider using something like execShield or your alternate preferred method to prevent buffer overflow attacks system-wide.

43. Set hostname to the simple, unqualified hostname, rather than the FQDN, if possible.

to be continued...

, Mike

Patching Solaris 10 Zones - Global And Local Issues

Hello Again,

In a long overdue continuation of our coverage of Solaris 10 (as in our previous post on migrating between local and global zones) today, we're going to take a look at patching on Solaris 10, insofar as it relates to zones. There are a lot of questions going around about how to patch appropriately and what's permissible. This is completely understandable since, if you do it wrong, the consequences can be disastrous and irreversible (and none of us wants to stay up all night... working ;)

We'll start off with the concept of patching and zones. As far as patching is concerned, each zone actually has it's own patch (and package) database. This makes it possible for you to, theoretically, patch single zones on a host individually or patch all of them at once by patching the "global" zone.

There are a few things to keep in mind though, before you go ahead and apply your patches, either way...

1. Even if you have "umpteen" number of zones on a single machine, they all run off of the same kernel, so if you have to patch your kernel (or anything kernel-related) you need to do that from the "global" zone. If you apply a kernel patch on a local zone, and bring its kernel patch revision to a different level than the "global" zone's (and other zones') calamity will ensue (Let's see how many different ways I can write that something bad is going to happen ;)

2. "patchadd" will eventually drive you nuts, anyway, so the following proviso's should be no surprise ;).

a. If you run patchadd with -G in a "global" zone, any packages that have SUNW_PKG_ALLZONES set to true will cause the entire patch operation to fail.

b. If you run patchadd with -G in a "global" zone and "no" packages have SUNW_PKG_ALLZONES set to true, you should be able to install the patch to all zones from the "global" zone.

c. If you run patchadd without -G in a "global" zone, regardless of the setting of SUNW_PKG_ALLZONES, you can install the appropriate patches to any individual zones or the global zone (which will patch all the zones, by default).

d. If you run patchadd in a "local" zone, with or without -G specified, any packages that have SUNW_PKG_ALLZONES set to true will fail and not install, and if none have SUNW_PKG_ALLZONES set to true, everything should work in each "local" zone you apply the patch to.

3. Any software that can be installed at the "local" zone level, can also be patched independently at the "local" zone level, on whatever zones it was installed. This is true regardless of your zone type (whole root or sparse root).

4. The "-G" option to patchadd doesn't stand for "global zone," rather it stands for "the current zone." I can't think of a good mnemonic for this so "G"ood Luck ;) Of course, if you use this flag in the "global" zone, you can pretend it makes sense and stands for that. I do...

5. The "-t" option to patchadd is available for people who got used to the old patch error code numbers and know them by heart (like me. Well... most of them). Even on a system with zones, they make it so only a return code of "0" indicates absolute success. Any other number indicates a problem.

6. The "-R" option to patchadd (with zones enabled) cannot be used to reference the root filesystem in any zone other than the "global" zone. If you choose to ignore this warning and use it on a "local" zone anyway, side effects may include damage to the "local" zone's filesystem, damage to the "global" zone's filesystem, security problems with the "global" zone's filesystem, nauseau, fatigue, dry-eye, constipation, arthritis and random "night terrors." Contact your doctor if you have any trouble breathing calmly while patching "global" zones, as this may be the sign of a rare, but serious, side effect ;)

Happy patching. Here's to eventually being allowed to do it on the weekdays :)

, Mike

linux unix internet technology

Using Solaris 10 Projects Absolutely or Per Process!

Most Solaris 10 users and admins already know that a whole lot about the Solaris OS changed when they switched from version 9 to 10. One of the most significant things that changed is the way Solaris deals with internal IPC settings, semaphores, shared memory and other kernel tunables.

In all previous versions, you needed to include those sorts of settings in /etc/system. The upside to this was that you could include all of your information in one file and easily report on all of your information by calling a common system command like "sysdef." Of course, one of the big disadvantages of having to set all of that stuff up in /etc/system was that you had to reboot your machine, every time you made a change, in order for the settings to take effect (/etc/system is read during the boot process at a level which can't be simulated at any user-operable run level)

In Solaris 10, a lot of the old setting in /etc/system have been deprecated. You can still include them without causing a problem with your boot process, but Solaris 10 will ignore most of the options you put in there with regards to the old system settings. The new preferred way of setting these variables in Solaris 10 is the "project." Among its many advantages, you can now modify a lot of settings, that used to require a reboot, on-the-fly!

This post isn't going to go into the entire "project" concept, but, instead, focus on two different ways of using it. That is, we'll be looking at using "project" settings on a "per user" basis and a "per action" basis.

Enabling project settings on a "per user" basis is generally preferred by most users. For instance, the oracle user account will want to have the maximum amount of shared memory set to an exact value in the kernel whenever it is invoked. The settings need to be the same all the time, and enabling project settings on "per user" basis is the easiest way to accomplish that.

For a small example; here is how we would set the oracle user up to always have its shared memory maximum set to 17GB (now matter how the account is called or used):

projadd -p 101 -c "Oracle User Account" -K "project.max-shm-memory=(privileged,17GB,deny)" -U oracle -G dba user.oracle

This will create an entry in /etc/project like:

user.oracle:101:Oracle User Account:oracle:dba:project.max-shm-memory=(privileged,17179869184,deny)

and you can check it out by running:

prctl $$

after logging in, to verify that things are as you like.

Now, you may want to make it so these values can be used on a "per action" basis. This way the user can log in and not necessarily have to use the project values assigned. This is preferrable if you only need to run certain processes with the project settings, but don't want them set while you do other things. The process is pretty much the same:

projadd -p 101 -c "Oracle User Account" -K "project.max-shm-memory=(privileged,17GB,deny)" -G dba user.oracle

This will create an entry in /etc/project like:

user.oracle:101:Oracle User Account::dba:project.max-shm-memory=(privileged,17179869184,deny)

Now when the user logs in, he or she can verify that the "project" settings aren't in effect by running "prctl $$" as above. Output should show that user is in the default project for the OS. He or she can now also take advantage of the project settings by using a command called "newtask," like so:

newtask -p user.oracle COMMAND

or attach to an existing process with:

newtask -v -p user.oracle -c PROCESS_ID

For the "per task" processes, you can verify that they're in effect for the process you started (or attached to) them with by doing:

prctl -i PROCESS_ID

or

prctl -n user.oracle (with, optionally, "-i PROCESS_ID" -- Running this without specifying the PROCESS_ID will show all processes running under the user.oracle project resource.

And that's it. Play around with it and have fun. Like we mentioned before, you can try this out a couple different ways until you get it just the way you like. With the new "project" method of setting kernel tunables, you'll not have to reboot any more between your iterations :)

, Mike

linux unix internet technology