The /etc/ directory

Leave a reply

In the last post we looked at /etc/passwd.  That file is in the /etc/ directory, which contains all sorts of configuration files.  This time, we’ll talk about that directory and some of the interesting files in it.

Like I said, it’s a configuration directory.  For example, your computer has an IP address.  If that’s a static IP address, then it’s going to be stored in a file in the /etc/ directory.

Every time you start your computer, it starts a lot of programs by default.  For example, it starts init, the mail program, the program that runs DNS, the printing system, cron, and more.  All of this is controlled by the files in /etc/.

There’s also some interesting files there.  For example, /etc/hostname.

Remember cron?  There’s a system file that runs all of the cron jobs for the system.  It’s in /etc/ too, in /etc/crontab.

There’s also our friend NTP, it has a configuration file there too.

The /etc/ directory was designed so that there wouldn’t be configuration files all over the system, instead, they’d be kept in one place.  This makes it much easier to manage the system, you don’t have to go searching in multiple directories to find the files.

Alpha:~ computerlamp$ cat /etc/hostname
Alpha

Yup, there’s the hostname of my computer.  Alpha.

Another file is /etc/motd, it contains the message of the day.   When you first open a terminal, you see the contents of this file. Sometimes it’s empty, sometimes it will have important messages, and sometimes it just has silly things:

Alpha:~ computerlamp$ cat /etc/motd
 _______
< Alpha >
 -------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Yes, that is cowsay in my /etc/motd file.  I was feeling whimsical.

The point of the /etc/ directory is to have the configuration files in one place, not scattered all over the computer.  It makes the system a lot easier to manage.

Plus, cowsay is fun!  All motd files should use cowsay!

The password file

Leave a reply

A while back I talked about how users have ids and how we can find out what they are using a command.  Remember, Linux loves files, so this information must be kept in a file somewhere.  It’s called the password file.  It should be called the ‘here are the users’ file, but it’s the password file.

You can actually look at this file.

Alpha:~ computerlamp$ more /etc/passwd

Here’s an example of what that can look like:

root:x:0:0:root:/root:/bin/tcsh
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/etc/news:

There’s 7 different parts to each line of this file and they’re separated by a colon (:).  Each part is:

  1. username
  2. password
  3. user ID
  4. group ID
  5. real name
  6. home directory
  7. login shell

Let’s pull apart each part of this file.  We know what the user name is, mine’s computerlamp.  What’s yours?

The next one is the password.  It looks weird in that file, there’s an x where you’d think we’d see the encrypted password.  That’s because it isn’t in this file, that’s actually what we call a placeholder.  It’s a ‘one used to be here, but isn’t any more’.  That’s because the actual encrypted password is now in a different file, /etc/shadow that only root can read.

Then there’s the user ID and group ID, we know what those are too and I’d assume you know what your real name is, right?

The last two are the home directory and login shell.  That’s the directory you’re dropped in when you first log in and the shell that you’re going to use.  My home directory is /home/computerlamp and my shell is /bin/bash.

There’s something weird in that result though, right?  For example, the user mail has a login password that’s /sbin/nologin.  If someone tries to login to that account, then they’ll get a polite ‘no, you can’t do that’ message and will be logged out.  Another way of doing this is by putting /bin/false as the shell.

Environment Variables

Leave a reply

Your environment can affect you.  If it’s raining and you’re sitting outside, well, then, you’re wet.  Sorry about that.  If you’re sitting inside with the air conditioning on, then you’re cool.  Turning on the air conditioning affects your environment, turning it off can make you warm again.  Bash has the same thing, you can turn things on and off again using environment variables.

They’re called variables because they can vary.  How’s that for a spiffy name?  Setting environment variables changes the behavior of your terminal session, they can also contain information about your terminal session as well.

They’re set by using the command export.  It looks like:

Alpha:~ computerlamp$ export VAR=VALUE

If you want to see all the environment variables in your session, just do:

Alpha:~ computerlamp$ export
declare -x G_BROKEN_FILENAMES="1"
declare -x HISTSIZE="1000"
declare -x HOME="/home/computerlamp"
declare -x HOSTNAME="Alpha"
declare -x INPUTRC="/etc/inputrc"
declare -x LANG="en_US.UTF-8"
declare -x LESSOPEN="|/usr/bin/lesspipe.sh %s"
declare -x LOGNAME="computerlamp"
declare -x LS_COLORS=""
declare -x MAIL="/var/spool/mail/computerlamp"
declare -x OLDPWD
declare -x PATH="/usr/local/bin:/bin:/usr/bin:/home/computerlamp/bin"
declare -x PWD="/home/computerlamp"
declare -x SHELL="/bin/bash"
declare -x SHLVL="1"
declare -x TERM="xterm-256color"
declare -x USER="computerlamp"

Let’s talk about a few of those from the list.

  1. USER . That’s my username!  Hi, I’m computerlamp.
  2. PWD  My current directory
  3. OLDPWD My previous directory.  There’s nothing set there because I haven’t done anything in this login aside from sit in my current directory
  4. HOME My home directory.  It’s the same as PWD right now, but it could be different.  It’s always set to my home directory.
  5. SHELL The shell I’m using, right now I’m using /bin/bash
  6. HOSTNAME That’s the hostname of this computer, which happens to be Alpha.

Now let’s talk about that PATH variable.  It’s several directories strung together with colons (:).   The path is all the directories that bash looks in when you want to execute a command.  My list is:

  1. /usr/local/bin/
  2. /bin/
  3. /usr/bin/
  4. /home/computerlamp/bin

When I try to run any command, bash starts by looking in /usr/local/bin/ for the command, then /bin/, next is /usr/bin/, and finally it tries /home/computerlamp/bin. If it can’t find it in any of those, it gives up and tells you that command isn’t available.

Now suppose I have two commands, /bin/Avenge and /usr/bin/Avenge.  One of them calls Tony Stark and the next calls Steve Rogers.

Captain America Civil War Clipart

Of course, at the end of Captain America:  Civil War, they are not getting along.

If I just run Avenge, it’s going to call Tony Stark by default.  If I want to call Steve Rogers, I’ll execute /usr/bin/Avenge.

crontab

Leave a reply

Last post we talked about cron and the basic format of the crontab file. This time we’re going to talk about more advanced examples of crontab. Remember, the fields are:

field Allowed Values
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)

I want my computer to beep on Sunday afternoon at 3:15 pm. The first field is 15 and the second field is 15. It isn’t 3, because that would be 3:15AM. I don’t know about you, but I’m asleep then. crontab uses military time where you add 12 to any time after noon. So 6pm becomes 18 for the crontab. I don’t care about the actual day of the month or the month, I want it every Sunday. So the third and fourth entries are * for the wildcard. For the last entry I can use either 0, 7, or Sun. I like Sun because it’s more descriptive. My crontab looks like:

15 15 * * Sun /home/computerlamp/beep.sh

I’ve decided I want my computer to beep on January 1 at midnight. It’s a way to celebrate the New Year! Happy New Year *beep*. The first two entries are 0, because I want 12:00AM, which is 0 minutes and 0 hours. The third entry is 1, for the first day of the month and the fourth is 1 or Jan for the first month of the year. I don’t really care what day of the week the first day of the year is, so I can put a wildcard for the fifth column. That makes my crontab look like:

0 0 1 1 * /home/computerlamp/beep.sh

I could also make it look like:

0 0 1 Jan * /home/computerlamp/beep.sh

We’ve talked about the format of the crontab but I haven’t said anything about how to edit it. That’s a more complex problem and we’ll talk about it in the next post.

cron

Leave a reply

In the last post we talked about scheduling things one at a time, which doesn’t work if we have things we want to repeat. Like I want my computer to make a beep every hour on the hour, I can either sit down and repeatedly run the at command until I’m sick of running the at command, or I can use a different system. That different system is cron.

That’s a weird name for a time keeping system. The story is (and who knows if this is true) it was named after the Greek god of time, Cronus.

Cronus

Cronus

Cron is very flexible. You can run things every hour, every day, every month, every week, every 5 minutes, thirty minutes after the hour, you get the idea. Any kind of regular time interval you want, you can run your program. It’s managed by a file called crontab.

Every user on a Linux system can operate a crontab, there’s no restrictions on that. It has a format you have to follow, otherwise it won’t work. The first five entries in the file are time related.
These  entries are minute, hour, day of month, month, and day of week.  Each of them have values you can put in:

field Allowed Values
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)

If I want something to run at midnight, then the first field is 0, the second is 0, but what about the third? I can use a ‘*’ to mean a wildcard. This means that on any day of the month, the job will run if the time matches the first two fields. I want it to run at midnight every day, so I put a * in the last two fields. If I want my computer to beep every night at midnight, my crontab would look like:

0 0 * * * /home/computerlamp/beep.sh

That program looks weird, right? Well in order for them to work, you have to give the full path of the program, otherwise the computer doesn’t know where to look.  Just like with at!

We’ll look at more examples of crontab next time.

Linux Schedule

20 Replies

People schedule things for all sorts of reason. There’s school schedules, lunch schedules… I bet Iron Man has a schedule for cleaning his suit. Which makes me wonder, what does Iron Man do for a bathroom if he’s in the suit for a long time?

Anyway, back to scheduling. Suppose I want my computer to make a beep in two hours to remind me to go watch The Avengers.It’s very important that I start watching in two hours because I want to follow it up with The Avengers: Age of Ultron and then I want to go have dinner and see Infinity War.

The Avengers!

The Avengers!

I want my computer to make a beep in two hours. The first question is, how do I make my computer beep?

One way to do it is by this:

Alpha:~ computerlamp$ echo -en "\a"

 

That’s a lot to remember, isn’t it? Let’s use nano and make a file we’ll call beep.sh

Here’s a picture of me making the file:

Making beep.sh

Making beep.sh

Remember, when you save it, call it beep.sh

The next thing to do is to change the permissions on the file. We want this to be executable.

Alpha:~ computerlamp$ chmod 755 beep.sh

Now we’ve made our first shell script. A shell script is a computer program that executes shell commands in the order that they’re in the file. So if we run beep.sh like this: 

Alpha:~ computerlamp$ ./beep.sh

 

we’ll get a beep! You’ve now written a computer program. How cool is that?

Now the next problem is how do we schedule this?

We use a program called at. I know, that’s a boring name. Now it’s 11 am and I want the computer to beep me at 1pm.

Alpha:~ computerlamp$ at -f /home/computerlamp/beep.sh 01:00PM

 

Now my computer knows that at 1PM it should run the program beep.sh, which means my computer will beep at me then.

How does this work? Well, there’s a daemon called atd that runs these jobs.

What if I want to run something every hour on the hour? I want to make my own cuckoo clock by making my computer beep at me every hour. We’ll talk about how tod o that next time.

Daemons

Leave a reply

Linux® has a lot of processes that run in the background. This means that they don’t disturb you when they run, they sit back there and, well, run. For example, the syslog process, the process that sends email, init, the great granddaddy of processes, they all sit back there and do their job without bothering you. They’re actually all called daemons.

Daemon in the flesh

Daemon in the flesh

That little guy is kind of cute, isn’t he?

The name came from a thought experiment known as Maxwell’s demon. In this experiment, an imaginary daemon moved things around in the background. They also come from Greek mythology, where the daemon is a guy working in the background but who isn’t necessarily up to no good. He’s not necessarily up to good either, he’s just back there doing his thing. The Greek Mythology spelling is the one that stuck for the daemons on the system.  That little guy is the mascot of the BSD® operating system.

A general rule is that daemons on the system end their name with ‘d’ so you know they’re daemons. syslogd is the daemon for syslog, dhcpd is the daemon that runs dhcp, and named is the daemon that runs DNS. This isn’t always true though, one of the main programs that handle email is called sendmail and so is it’s daemon. There’s no d at the end of that one.

I ran apropos daemon to see what I’d get:

arpd (8) - userspace arp daemon.
authorized_keys (5) - OpenSSH SSH daemon
blkmapd (8) - pNFS block layout mapping daemon
cron (8) - daemon to execute scheduled commands (Vixie Cron)
daemon (1) - turns other processes into daemons
daemon.conf (5) - turns other processes into daemons
dbus-daemon (1) - Message bus daemon
epmd (1) - Erlang Port Mapper Daemonepmd [-d|-debug] [DbgExtra...] [-port No] [-daemon] [-relaxed_command_c...
faked (1) - daemon that remembers fake ownership/permissions of files manipulated by fakeroot processes.
faked-sysv (1) - daemon that remembers fake ownership/permissions of files manipulated by fakeroot processes.
faked-tcp (1) - daemon that remembers fake ownership/permissions of files manipulated by fakeroot processe

 

This isn’t all of the output, I just chose the first few lines. You should do it on your system to see what you’ll get but there’s a lot of results, aren’t there?

We’ll talk about some of these daemons in the future, because most of them are important to keep your Linux® system running happily.

Keylogger — Stealing your Typing for Fun and Profit

Leave a reply

The last post about the last command got me think about security again and how people can get your password to log into your system.  Passwords on the Linux® system are one-way cryptography, so a bad guy shouldn’t be able to break it.  There is a tool a bad guy can use to get your password, it’s called a keylogger.

A key logger is a program that records every single key stroke you make.

A keyboard

A keyboard

Imagine someone sitting inside your keyboard and recording every command you type.  It could also record you entering your password and then it would have your password.

That’s a scary thought, right?   How do you get hit with key loggers?

They’re a virus.   Bad guys use them for more than just stealing your password, they’re also used for stealing credit card information and social security numbers.  They really want to steal money, your identification, and anything else they can sell.

They’re also often installed as a hardware addition.  The program is on a USB stick, is stuck into a slot on to your computer, and then the keylogger saves all it can onto the USB stick and waits for someone to come and get it.

If someone has physical access to your computer, they have all the time in the world to break into it.  They need the physical access to put the keylogger on, so all they have to do is walk up, slip it on, and walk away.  They do hope that you won’t find it.

If they steal the computer from you, they also have all the time in the world to get your information off of it. It’s one of the main tenets of computer security, keep your computer physically secure.  Imagine if a CEO’s laptop walked off?  CEOs have lots of information on their computers about the company, if the bad guy has it, then all that information is up for grabs.

 

last

Leave a reply

Every time you log in to your Linux® system, a log entry is made.  It is important for security, what if you logged in while you were asleep?  Either you were sleep typing or someone got your password.  Either way, that’s important information.  Lucky for us, Linux® logs this and there’s an easy way to see when you logged in.  That command is last.

If someone does log in and pretend to be you, then that person who isn’t you wants you not to know that you logged in when you didn’t actually log in.

Wait, let me try that again.

If the bad guy logs into the system, he wants to hide from you that he logged in.

Ultron went traipsing around the Internet and he didn’t care if anyone knew what he was up to.

Ultron up to no good

Ultron up to no good

Other bad guys do care so their first attempt is to remove these messages.

Linux® tries to make this hard.  Most log files are straight boring plain text.  That means you can look at them and even edit them and no one will know the difference.

The file that last reads from isn’t like that. It’s a binary file, which means that you an’t edit it at all without mucking things up.

The output of the command looks like this:

computerlamp    pts/2        console Thu Mar 15 20:53   still logged in
computerlamp    pts/2        console Wed Mar 14 20:52 - 20:53  (00:00)
computerlamp    pts/2        console Fri Mar  9 21:24 - 21:34  (00:10)
computerlamp    pts/1        console Sat Feb 24 15:56 - 17:13  (01:17)
computerlamp    pts/0        console Fri Feb 23 14:30 - 15:47  (01:17)
reboot   system boot         console Fri Feb 23 13:59         (20+05:53)
computerlamp    pts/2        console Wed Feb 21 20:06 - 20:16  (00:09)

It shows you when I logged into the system, when I logged out, it shows you that there was a reboot of the system as well.  If I looked over this and said ‘now wait a minute, I was out of town February 23, what happened there?’ then I would be investigating a possible break in of my system.

dmesg

Leave a reply

Remember the Linux Kernel and Device Drivers?  They log like everything else.  They also write their log messages to a special file and there’s a command dmesg that lets you see what’s in the file.

The special file has a name and it’s the ring buffer.

The One Ring

The One Ring

This doesn’t mean you have a ring in your computer.  No hobbits are going to go on a quest to retrieve the one ring, sorry.  Go watch The Lord of the Rings to see that ring.

Instead, the ring buffer is a way of storing the messages.  Think of it like a pile of blocks.

A pile of blocks

A pile of blocks

We only want the pile of blocks to be four blocks high, so every time we add a block to the bottom, we must remove one of the blocks from the top.  That’s how the ring buffer works.  It only has a certain amount of information it can store so when that amount is reached, the oldest message in the ring buffer gets removed and the newest one is added.

Next question, what do the messages look like?  Well, you can run the command dmesg  and find out.  Some systems have that command restricted because the people who run the system think it’s a security leak.  It can be, if a device driver is complaining a lot a malicious person can take advantage of that.

I’m here to save the day, though, and show you what an output can look like:

___slab_alloc+0x37a/0x4a0
 ? __es_insert_extent+0x84/0x2f0
 ? ext4_ind_map_blocks+0x102/0xc70
 ? ext4_ind_map_blocks+0x584/0xc70
 __slab_alloc+0x27/0x40
 ? __slab_alloc+0x27/0x40
 ? __es_insert_extent+0x84/0x2f0
 kmem_cache_alloc+0xd5/0x180
 ? __es_insert_extent+0x84/0x2f0
 ? __es_insert_extent+0x84/0x2f0
 __es_insert_extent+0x84/0x2f0
 ext4_es_insert_extent+0xbf/0x190
 ext4_map_blocks+0x262/0x630
 ? __add_to_page_cache_locked+0xb0/0x170
 ext4_mpage_readpages+0x282/0xa20
 ? __raw_callee_save___pv_queued_spin_unlock+0x9/0x10
 ? queue_unplugged+0x33/0xa0
 ? alloc_pages_current+0x58/0xb0
 ext4_readpages+0x29/0x40
 ? ext4_readpages+0x29/0x40
 ? ext4_journalled_zero_new_buffers+0x110/0x110
 __do_page_cache_readahead+0x131/0x1e0

That’s not very helpful, is it?  It requires a lot of knowledge to understand the output of dmesg and it’s usually used when the person running the system notes a problem.  When a system is restarted, the ring buffer is full of information about starting processes, so that can be useful then as well.