|
|
 slmingol posted this in tips & tricks on March 26th, 2010, @ 11:54 amI can never find these clearly defined in any man page so I’m putting them here the next time I need them.
The list of syslog severity Levels
0 – Emergency – system is unusable
1 – Alert – action must be taken immediately
2 – Critical – critical conditions
3 – Error – error conditions
4 – Warning – warning conditions
5 – Notice – normal but significant condition
6 – Informational – informational messages
7 – Debug – debug-level messages
Recommended practice is to use the Notice or Informational level for normal messages.
A detailed explanation of the severity Levels
DEBUG:
Info useful to developers for debugging the application, not useful during operations
INFORMATIONAL:
Normal operational messages – may be harvested for reporting, measuring throughput, etc – no action required
NOTICE:
Events that are unusual but not error conditions – might be summarized in an email to developers or admins to spot potential problems – no immediate action required
WARNING:
Warning messages – not an error, but indication that an error will occur if action is not taken, e.g. file system 85% full – each item must be resolved within a given time
ERROR:
Non-urgent failures – these should be relayed to developers or admins; each item must be resolved within a given time
ALERT:
Should be corrected immediately – notify staff who can fix the problem – example is loss of backup ISP connection
CRITICAL:
Should be corrected immediately, but indicates failure in a primary system – fix CRITICAL problems before ALERT - example is loss of primary ISP connection
EMERGENCY:
A “panic” condition – notify all tech staff on call? (earthquake? tornado?) – affects multiple apps/servers/sites…
Useful Links
slmingol posted this in tips & tricks on March 12th, 2010, @ 11:10 am
Background
A system’s BIOS is a treasure trove of a lot of useful info about the capabilities of a computer. BIOS, which stands for Basic Input/Output System, contains information such as:
- motherboard manufacturer
- system’s serial number
- amount of RAM installed
- the CPUs speed & signature
Normally the BIOS is accessible by pressing the delete key or the F1 key while your computer is booting up.
Problem
Occasionally I’ve wanted to check out the BIOS settings of a system without having to go through the hassle of rebooting. With the help of this nifty command line tool, dmidecode, BIOS info can be had, without having to reboot.
Solution
…from the dmidecode man page…
dmidecode is a tool for dumping a computer’s DMI (some say SMBIOS) table contents in a human-readable format. This table contains a description of the system’s hardware components, as well as other useful pieces of information such as serial numbers and BIOS revision. Thanks to this table, you can retrieve this information without having to probe for the actual hardware. While this is a good point in terms of report speed and safeness, this also makes the presented information possibly unreliable.
The DMI table doesn’t only describe what the system is currently made of, it also can report the possible evolutions (such as the fastest supported CPU or the maximal amount of memory supported).
SMBIOS stands for System Management BIOS, while DMI stands for Desktop Management Interface. Both standards are tightly related and developed by the DMTF (Desktop Manage- ment Task Force).
Example output from a Thinkpad T42 laptop
When you first run the dmidecode command it tells you a summary of how many structures are present within your system’s BIOS.
1
2
3
4
5
| % dmidecode
# dmidecode 2.9
SMBIOS 2.33 present.
61 structures occupying 2126 bytes.
Table at 0x000E0010. |
Each structure is represented by a handle ID which is a hex value of the form 0x001F, followed by it’s type and it’s size.
…. Continue reading → [one-liner]: Analyzing a System’s BIOS from the Command Line under Fedora, CentOS, or RHEL »»
slmingol posted this in tips & tricks on September 27th, 2009, @ 3:17 am
Now that I’ve been using OpenVZ for several months I’d gotten to the point where I wanted/needed to “yum update” all my VEs. I currently have 11 images running on my OpenVZ Server. I thought I could just vzctl exec … yum -y update all the VEs, but quickly ran into some issues with this brute force approach. Doing the yum -y update broke several of my VEs so I opted to restore the unrecoverable ones from backups.
For my second attempt, I opted to do each VE independently, to get a better understanding of what the best approach would be for doing mass upgrades like this now, and in the future. The first hurdle to overcome had to do with some of the VEs running out of memory (RAM) during the upgrade process.
NOTE: A VE = Virtual Environment (aka. a virtual host), while HN = Host Node
Issue #1, not enough RAM for yum to run
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
26
27
28
29
30
31
| # RAM budgets for VEs
# NOTE: values are in # of pages (1 pg. = 4K)
% (printf "vm feature held maxheld barrier limit failcnt\n"; grep privvm /proc/bc/1*/resources)|column -t
vm feature held maxheld barrier limit failcnt
/proc/bc/101/resources: privvmpages 31904 82215 65536 69632 2
/proc/bc/102/resources: privvmpages 119803 196620 166400 179200 9517
/proc/bc/103/resources: privvmpages 27125 35974 65536 69632 0
/proc/bc/104/resources: privvmpages 56251 107250 104960 115200 0
/proc/bc/105/resources: privvmpages 73559 82926 98304 103304 0
/proc/bc/106/resources: privvmpages 30219 68097 65536 69632 0
/proc/bc/108/resources: privvmpages 30081 84291 65536 69632 1
/proc/bc/109/resources: privvmpages 32790 74199 98304 103304 0
/proc/bc/110/resources: privvmpages 40497 69408 65536 69632 1
/proc/bc/111/resources: privvmpages 26990 35371 65536 67840 0
# NOTE: converted the columns to megabytes (MB), it's just easier to read
(printf "vm feature held maxheld barrier limit failcnt\n"; grep privvm /proc/bc/1*/resources|awk '{sub($3,$3*4096/2^20) sub($4,$4*4096/2^20) sub($5,$5*4096/2^20) sub($6,$6*4096/2^20)}1')|column -t
vm feature held maxheld barrier limit failcnt
/proc/bc/101/resources: privvmpages 124.625 321.152 256 272 2
/proc/bc/102/resources: privvmpages 467.98 768.047 650 700 9517
/proc/bc/103/resources: privvmpages 105.957 140.523 256 272 0
/proc/bc/104/resources: privvmpages 219.73 418.945 410 450 0
/proc/bc/105/resources: privvmpages 287.34 323.93 384 403.531 0
/proc/bc/106/resources: privvmpages 118.043 266.004 256 272 0
/proc/bc/108/resources: privvmpages 117.504 329.262 256 272 1
/proc/bc/109/resources: privvmpages 128.086 289.84 384 403.531 0
/proc/bc/110/resources: privvmpages 158.191 271.125 256 272 1
/proc/bc/111/resources: privvmpages 105.43 138.168 256 265 0 |
According to this data 4 of the 11 images had gone over their allocation of RAM. So I tried restarting these and re-running yum update within the problem VEs. Again the update failed and so I needed to increase their allocation of memory. I didn’t want to devote more memory permanently, just a enough temporarily to do the upgrade. So I used this trick to temporarily bump up a VEs allocated memory.
1
2
3
4
5
6
7
8
9
| # increase the RAM by 100MB
vzctl set 101 --privvmpages $((256+100))m:$((272+100))m --save
# ...
# do the upgrade (yum update)
# ...
# decrease the RAM back to the original value
vzctl set 101 --privvmpages 256m:272m --save |
For the remaining 3 VEs that needed additional memory I used these commands to increase their allocations of RAM
1
2
3
4
5
6
7
8
9
| # cmds. to increase RAM by 100MB
vzctl set 102 --privvmpages $((650+100))m:$((700+100))m --save
vzctl set 108 --privvmpages $((256+100))m:$((272+100))m --save
vzctl set 110 --privvmpages $((256+100))m:$((272+100))m --save
# cmds. to decrease
vzctl set 102 --privvmpages 650m:700m --save
vzctl set 108 --privvmpages 256m:272m --save
vzctl set 110 --privvmpages 256m:272m --save |
Issue #2, not enough diskspace for yum to run
The next snag I ran into had to do with a couple of the VEs running out of diskspace. And here’s the commands I used to reconfigure more diskspace.
…. Continue reading → Keeping CentOS 5 OpenVZ images up to Date with Yum »»
slmingol posted this in tips & tricks on September 5th, 2009, @ 1:13 am
As it is with UNIX & Linux there is always another way. In my previous article [one-liner]: Filtering ps from ps, one reader, Christoph, mentioned an alternative method to the one I outlined. In this case, I would consider his to be a better way, so I thought I would take a second to demonstrate this alternative method. The alternative? Use the command pgrep.
The Original Approach
My original post offered the following one-liner:
1
2
3
4
5
6
7
8
9
10
| % ps -eaf | grep "[h]ttpd"
root 2683 1 0 2008 ? 00:20:31 /usr/sbin/httpd
apache 17146 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17147 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17149 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17150 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17151 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17152 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17153 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17154 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd |
This one-liner provided a list of all the httpd processes running, while filtering out the actual string from the grep httpd command.
The Alternative Approach
By using the command pgrep, the same effect can be achieved and a lot more. For starters, you can get a list of all the httpd PIDs:
1
2
3
4
5
6
7
8
9
| # list of httpd PIDs
% pgrep httpd
1608
7645
9739
10051
27712
27859 |
This could be useful in a shell script, if needed, to check for any running httpd processes. For example:
1
2
3
4
| # test for httpd processes
% [ -z "`pgrep httpd`" ] || echo "running"
running |
Here are some other examples:
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
26
27
28
29
30
31
| # list of PIDs with corresponding command name
% pgrep -l httpd
1608 httpd
7645 httpd
9739 httpd
10051 httpd
27712 httpd
27859 httpd
# list of PIDs with corresponding command name owned by user root
% pgrep -l -u root httpd
1608 httpd
# list of PIDs, separated with a comma delimiter
% pgrep -d, httpd
1608,7645,9739,14119,14162,27859
# detailed list of httpd PIDs via ps
# NOTE: $(...) runs the command above, returning the list of PIDs to ps
% ps -fp $(pgrep -d, httpd)
UID PID PPID C STIME TTY TIME CMD
root 1608 1 0 Aug03 ? 00:00:05 /usr/sbin/httpd
apache 7645 1608 0 Sep04 ? 00:00:47 /usr/sbin/httpd
apache 9739 1608 0 Sep04 ? 00:01:50 /usr/sbin/httpd
apache 14119 1608 0 Sep04 ? 00:00:13 /usr/sbin/httpd
apache 14162 1608 0 Sep04 ? 00:00:13 /usr/sbin/httpd
apache 27859 1608 0 Sep04 ? 00:07:19 /usr/sbin/httpd |
Thanks again to Christoph for pointing out this alternative.
NOTE: For further details regarding my one-liner blog posts, check out my one-liner style guide primer.
slmingol posted this in tips & tricks on September 4th, 2009, @ 1:13 pm
Background
This is a pretty handy trick to know when you want to filter out the command you’re running, so that it’s not included in ps output. This proves handy when writing a shell script that needs to parse output from ps.
NOTE: The command ps, allows you to see all the processes being run on a UNIX/Linux system. You typically use it with the switches “-eaf” or “-ef”.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| # columns description:
# UID = user who owns the process
# PID = process #
# PPID = parents' process #
# C =
# STIME = start time
# TTY = terminal type (has to do with which shell command ran from)
# TIME = system time its run
# CMD = command (aka. program name)
% ps -eaf
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 2008 ? 00:24:46 init [5]
root 2 0 0 2008 ? 00:00:00 [kthreadd]
root 3 2 0 2008 ? 00:01:58 [migration/0]
root 4 2 0 2008 ? 00:23:13 [ksoftirqd/0]
root 5 2 0 2008 ? 00:00:00 [watchdog/0]
root 6 2 0 2008 ? 00:02:35 [migration/1]
root 7 2 0 2008 ? 00:09:55 [ksoftirqd/1]
root 8 2 0 2008 ? 00:00:00 [watchdog/1]
root 9 2 0 2008 ? 00:06:36 [events/0]
root 10 2 0 2008 ? 00:06:16 [events/1]
root 11 2 0 2008 ? 00:00:10 [khelper]
root 54 2 0 2008 ? 00:19:26 [kblockd/0] |
Problem
Here’s an example where we want to see if a program is running, so we grep the output of ps like so:
1
2
3
4
5
6
7
8
9
10
11
| % ps -eaf | grep httpd
root 2683 1 0 2008 ? 00:20:31 /usr/sbin/httpd
user1 13188 3984 0 12:45 pts/1 00:00:00 grep httpd
apache 17146 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17147 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17149 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17150 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17151 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17152 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17153 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17154 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd |
The problem? Notice that a portion of our command, “grep httpd” is polluting our ps output. How can we get rid of it?
The Trick
You can alter what you are grepping for, without actually altering the results, by using a benign regular expression.
1
2
3
4
5
6
7
8
9
10
| % ps -eaf | grep "[h]ttpd"
root 2683 1 0 2008 ? 00:20:31 /usr/sbin/httpd
apache 17146 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17147 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17149 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17150 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17151 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17152 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17153 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd
apache 17154 2683 0 Aug30 ? 00:00:02 /usr/sbin/httpd |
Explanation
…. Continue reading → [one-liner]: Filtering ps from ps »»
slmingol posted this in tutorials on August 20th, 2009, @ 2:31 am
If you’ve followed my blog for a while you’ve probably noticed that I like to automate just about everything. I can’t stand doing anything manual, at least more than once. So of course when I setup a network printer, I like to have the Windows drivers that go along with each printer available automagically over the network. This technique isn’t glaringly obvious so I thought I’d quickly document how I accomplished it.
Background
This technique requires that you already have both Samba & CUPS servers setup and configured. You should also already have the printer whose drivers we’re going to install configured and working through CUPS. You can read how I did this for the MFC-8480DN printer in this previous post.
Getting Started
First things first, you typically want to grab a copy of the Windows drivers for your particular printer. Remember, in this example I’m using the network capable, Brother MFC-8480DN, that I discussed in this previous post. I downloaded the Windows drivers from the Brother’s website here. Here’s a link the specific driver bundle that I used. Brother calls this bundle the “Add Printer Wizard Driver”. I then set them aside, so I could focus on getting the special Samba share, print$, configured. This is a special share where print drivers for all versions of Windows can be staged, for later consumption by Windows client systems that add this printer.
Samba
adding the print$ share
For my setup, which is a CentOS 5 system, I added the following stanza to my /etc/samba/smb.conf file.
1
2
3
4
5
6
7
8
9
| # /etc/samba/smb.conf
[print$]
comment = Printer Driver Download Area
path = /etc/samba/drivers
browseable = yes
guest ok = yes
read only = yes
write list = @samba-printers, root |
NOTE: The unpacked driver files that get added to the print$ share will be stored under /etc/samba/drivers on the Samba server. You can put them really anywhere, but I chose to keep them with the Samba config. files.
samba-printers Linux Group
Next, I created a special Linux group that I arbitrarily called samba-printers. Users in this group, in addition to root, will be the only users that have permission to add Windows drivers to the print$ Samba share. I accomplished this by adding the line below to the /etc/group file on the Samba server.
1
2
3
| # /etc/group file on Samba server
samba-printers:x:1020:root,user1,user2 |
The 2 user accounts, user1 & user2, are both Linux accounts as well as Windows accounts. In my home network I typically create them this way to make things like this simpler. If you happen to user different user accounts on Windows vs. Linux you can map the Windows accounts to Linux accounts through the Samba config. file /etc/samba/smbusers.
creating /etc/samba/drivers
Next, I created the directory /etc/samba/drivers and permissioned it with our newly created Linux group using these commands:
1
2
| mkdir -m ug+rwx,o-w,g+s /etc/samba/drivers
chgrp samba-printers /etc/samba/drivers |
…. Continue reading → Howto Install Windows Print Drivers onto a Central Samba Share »»
|
March 26th, 2010, @ 11:54 am |
Tags: 
Category: 
