|
|
 slmingol posted this in tutorials on May 24th, 2013, @ 6:51 pmBackground
If you’ve ever gone poking around in your Linux system’s /sbin directory the site of files like this might make you scratch your head.
1
2
3
4
5
6
7
8
| lrwxrwxrwx 1 root root 3 Jun 7 2011 vgmerge -> lvm
lrwxrwxrwx 1 root root 3 Jun 7 2011 vgmknodes -> lvm
lrwxrwxrwx 1 root root 3 Jun 7 2011 vgreduce -> lvm
lrwxrwxrwx 1 root root 3 Jun 7 2011 vgremove -> lvm
lrwxrwxrwx 1 root root 3 Jun 7 2011 vgrename -> lvm
lrwxrwxrwx 1 root root 3 Jun 7 2011 vgs -> lvm
lrwxrwxrwx 1 root root 3 Jun 7 2011 vgscan -> lvm
lrwxrwxrwx 1 root root 3 Jun 7 2011 vgsplit -> lvm |
We’ll read on and I’ll explain how all these seemingly regular tools are actually just one.
So What’s going on?
Many programs make use of this technique where there is a single executable that changes it’s behavior based on how it was executed.
There’s typically a structure inside the program called a case/switch statement that determines the name the executable was called with and then will call the appropriate functionality for that executable name. That name is usually the first argument the program receives. For example, in the C programming language when you write:
1
| int main(char** argv, int argc) |
argv[0] contains the name of the called executable. At least, this is the standard behavior for all shells, and all executables that use arguments should be aware of it.
Example in Perl
Here’s a contrived example I put together in Perl which shows the technique as well.
…. Continue reading → Why are “executables” such as reboot, shutdown, and vgscan symlinks in the /sbin directory? »»
slmingol posted this in tutorials on May 21st, 2013, @ 8:17 pm
Background
A question came up on the Stack Exchange site Unix & Linux in which I wrote up a pretty good answer, that describes some of the mechanics of how a process deals with its user credentials, so I’m adding my writeup to the blog.
It really comes down to what makes up a process in Unix. A process can come into existence in one of 2 ways. Either via the fork() function or through one of the exec() functions in C.
fork()
fork() basically just makes a copy of the current process, but assigns it a new process ID (PID). It’s a child of the original process. You can see this relationship in the output of @ps@:
1
2
3
4
5
6
7
| $ ps axjf
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
1 5255 1964 1964 ? -1 Sl 500 0:39 gnome-terminal
5255 5259 1964 1964 ? -1 S 500 0:00 \_ gnome-pty-helper
5255 18422 18422 18422 pts/1 18422 Ss+ 500 0:01 \_ bash
5255 30473 30473 30473 pts/4 30473 Ss+ 500 0:00 \_ bash
30473 782 782 30473 pts/4 30473 Sl 500 1:14 | \_ evince s.pdf |
Here you can see that gnome-terminal is the parent process (PID = 5255) and that bash is it’s child (PID = 18422, PPID = 5255).
When a process forks from its parent, it “inherits” certain things, such as copies of all the file descriptors that the parent currently has for open files and the parent’s user and group IDs.
NOTE1: PPID = Parent Process ID.
NOTE2: The last 2 are what identify what file and group permissions this process will have when accessing the file system.
So if a process just inherits its user and group ID from its parent, then why isn’t everything just owned by root or a single user? This is where exec() comes in.
exec() Part #1
…. Continue reading → How does a process deal with user credentials? »»
slmingol posted this in tutorials on May 18th, 2013, @ 8:50 pm
Background
People that use Linux on a daily basis probably are completely oblivious to the actual mechanisms being used to store their passwords safely and securely on a given Linux system. Oh they might guess that their password is stored in the /etc/passwd file (they’d be wrong by the way) but most probably never even gave it a passing thought. So I thought I’d take the opportunity to shed some light on how Linux systems “stash” your precious password away.
Solution
So if your password isn’t actually stored in the /etc/passwd file then where does it get stored?
Answer: the /etc/shadow file.
This file is where all the keys to each user’s account are kept for safe keeping. Obviously only the root user can peer inside this file so all the commands we’ll be dealing with in this post, it should be assumed that you’ll need to either be root, or use sudo to run.
/etc/shadow
A typical /etc/shadow entry:
1
| root:$6$bbmDJwcZHy5bgEDz$kFO.W/T7nUqcszZWl5RglxoDDAcDxevWpHVfN3v3f.Cx2ZeMcn5PX23VvnnkgtNWZf8hYtqsL0pPkZqyj50NY/:14362:0:33333:7::: |
NOTE1: Don’t get too excited, the above isn’t really my entry, I made this one up.
NOTE2: Each field is separated by a colon (:) & we’re only concerned with the first two columns!
dissecting the hash
The key pieces to notice in that line of what looks like gibberish is the following:
- The first column,
root is the user whom this entry belongs to from the /etc/passwd file.
- The second column,
$6$..... is essentially the user’s hashed password.
Taking the second column apart further you should start to notice that’s it’s not complete gibberish after all.
For example:
- the first couple of characters,
$6$, is a mark that tells the system what type of hashing was used to hash the password.
- The text between the next set of dollar signs,
$bbmDJwcZHy5bgEDz$, is the actual salt that was used to hash your password.
- Everything else after, is your password + salt hashed using whatever hash function was specified at the beginning, $6$, in our example here.
Specifically if you look at the man page for the crypt command, man 3 crypt there is a section that discusses what the $6$ notation means:
So $5$salt$encrypted is an SHA-256 encoded password and $6$salt$encrypted is an SHA-512 encoded one.
NOTE: So in our case the password + salt is being hashed using the SHA-512 scheme.
design details
…. Continue reading → How is my password stored in Linux? »»
slmingol posted this in tips & tricks on April 21st, 2013, @ 7:41 am
Background
If you’ve every dealt with Conky you may have gotten a little confused when you’re trying to get it to display your CPU frequency like so:
… and Conky is reporting your CPU frequency as 1.12GHz when in fact it’s actually much higher than that, say 2.67GHz. Most likely this is being caused by the CPU governing features that are present in most modern hardware. Here’s a behind the scenes 5 second tour of seeing what’s going on within your Linux Kernel.
Solution
First, from the conky man page.
cpu (cpuN)
CPU usage in percents. For SMP machines, the CPU number can
be provided as an argument. ${cpu cpu0} is the total usage, and ${cpu
cpuX} (X >= 1) are individual CPUs.
freq_g (n)
Returns CPU #n’s frequency in GHz. CPUs are counted from 1.
If omitted, the parameter defaults to 1.
You most likely have something like SpeedStep enabled which is acting like a governor on a car, regulating the speed of the cores inside your CPU. You can confirm that this is going on by looking at the output of this command:
1
2
3
4
5
6
7
8
9
| % less /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz
stepping : 5
cpu MHz : 1199.000
... |
The 2 numbers that matter are the 2.67GHz, that the GHz that my CPU is rated to operate at followed by the number 1199.00, this is what my CPU is allowed to run at by the governor setup on my Linux laptop.
You can see what governor is currently configured like so:
…. Continue reading → [one-liner]: Why is Conky reporting a lower CPU frequency, when my CPU frequency is actually much higher? »»
slmingol posted this in tips & tricks on April 15th, 2013, @ 5:50 pm
Background
Here’s a quick tip for checking out the overall health of your computer’s hard drive. It makes use of a little known tool called udisks which provides access to information about storage devices from the D-Bus interface.
Solution
Before we jump into udisks here are some resources that might prove useful when dealing with the design/architecture of udisks.
To see which drives are currently under udisks watchful eye, you can use the following command:
1
2
3
4
5
6
7
8
9
10
11
12
| % sudo udisks --enumerate
/org/freedesktop/UDisks/devices/dm_2d0
/org/freedesktop/UDisks/devices/dm_2d1
/org/freedesktop/UDisks/devices/dm_2d2
/org/freedesktop/UDisks/devices/sda1
/org/freedesktop/UDisks/devices/sda2
/org/freedesktop/UDisks/devices/sda3
/org/freedesktop/UDisks/devices/sda4
/org/freedesktop/UDisks/devices/sda5
/org/freedesktop/UDisks/devices/sda6
/org/freedesktop/UDisks/devices/sr0
/org/freedesktop/UDisks/devices/sda |
This output shows that I have several partitions that are currently bing monitored, the last bit in the path tells you which device, i.e. sda1, sda2, sda3, etc. These are partitions /dev/sda1, /dev/sda2, etc.
Now on to the actual health output. This next command will show you the overall health of device /dev/sda, i.e. my primary HDD on my laptop:
…. Continue reading → [one-liner]: Checking out a HDD’s Health using the Command Line Tool udisk »»
slmingol posted this in tips & tricks on January 19th, 2013, @ 10:50 pm
Background
In my experience it can be tricky to compile applications that make use of 3rd party libraries and/or system libraries such as glibc etc. The problem is that in addition to your application being built statically, all these libraries need to provide both a dynamic (.so) version as well as a static version (.a) and some libraries just don’t provide this, at least not easily. So you’re forced to compile everything down the stack of dependencies yourself and this can be tough.
Solution
That being said, here courtesy Rick Vanderzwet’s Blog, is a one way to compile subversion statically:
1
2
3
4
5
6
| % curl -O wget http://archive.apache.org/dist/subversion/subversion-1.7.8.tar.gz
% tar zxvf subversion-1.7.8.tar.gz
% cd subversion-1.7.8/
% ./get-deps.sh
% ./configure --with-ssl --without-gssapi --without-swig --enable-all-static
% make |
Confirm with the following commands:
size of executable?
1
2
| % ls -lh subversion/svn/svn
-rwxrwxr-x 1 saml saml 11M Jan 19 22:09 subversion/svn/svn |
executable runs?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| % subversion/svn/svn --version
svn, version 1.7.8 (r1419691)
compiled Jan 19 2013, 22:03:50
Copyright (C) 2012 The Apache Software Foundation.
This software consists of contributions made by many people; see the NOTICE
file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository access (RA) modules are available:
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- handles 'http' scheme
- handles 'https' scheme |
what does the executable depend on?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| % ldd subversion/svn/svn
linux-vdso.so.1 => (0x00007fffd7463000)
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00000034fc600000)
libm.so.6 => /lib64/libm.so.6 (0x00000034e7600000)
libssl.so.10 => /usr/lib64/libssl.so.10 (0x0000003210800000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x000000399a000000)
libz.so.1 => /lib64/libz.so.1 (0x00000034e8600000)
libmagic.so.1 => /usr/lib64/libmagic.so.1 (0x00000034ef600000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00000034eb200000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00000034eda00000)
librt.so.1 => /lib64/librt.so.1 (0x00000034e8a00000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00000034f5e00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000034e7e00000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000034e7a00000)
libc.so.6 => /lib64/libc.so.6 (0x00000034e7200000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00000034ea200000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x000000320f800000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003210000000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003d3ce00000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003210400000)
/lib64/ld-linux-x86-64.so.2 (0x00000034e6e00000)
libfreebl3.so => /lib64/libfreebl3.so (0x00000034f6200000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x000000320fc00000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00000034f3a00000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00000034e8e00000) |
This last bit shows that this executable is still dependent on several dynamic libraries but it’s much less than a typical dynamically built subversion!
References
links
NOTE: For further details regarding my one-liner blog posts, check out my one-liner style guide primer.
Page 1 of 912345...»Last »
|
May 24th, 2013, @ 6:51 pm |
Tags: 
Category: 
