CentOS and Fedora Linux use a set of directories in /etc to control when jobs run. These directories take the following form:
/etc/cron.hourly - jobs that run once per hour
/etc/cron.daily - jobs that run once per day
/etc/cron.weekly - jobs that run one per week
/etc/cron.monthly - jobs that run once per month
To add a job to run hourly, daily, weekly or monthly, you can drop an executable shell script in the pertinent directory. I recently became curious which time of the day daily jobs execute, which day weekly jobs run, and when monthly jobs were scheduled. The answer to these questions comes in the way of /etc/crontab, which contains crontab formatted entries that call the run-parts script to invoke the scripts in the hourly, daily, weekly or monthly directory.
The PCI and PCI express interconnect technologies have become the defacto standard for connecting peripherals to most motherboards. 64-bit 66 MHZ PCI interconnects run with speeds up to 528MB/s, and share the available bandwidth between devices on the PCI bus. PCI express x32 runs with speeds up to 8 GB/s, and provides dedicated “lanes” to connect each peripheral directly to the motherboards chipsets. This allows PCI express devices to utilize all of the available bandwidth, and maximizes throughput since PCI express devices do not need to compete with other devices on the bus. On systems that utilize gigabit Ethernet and 4 GB/s HBAs, it is possible to saturate a 33 or 66 MHZ PCI bus during peak loads. If you happen to be using a PCI interconnect and the Solaris Operating System, you can easily measure the current PCI bus utilization with the busstat(1m) command:
$ busstat -w pcis0,pic0=dvma_cycles,pic1=dvma_wd_xfr -w
pcis1=pic0=dvma_cycles,pic1=dvma_wd_xfr 5**
time dev event0 pic0 event1 pic1
5 pcis0 dvma_cycles 482928 dvma_wd_xfr 115184
5 pcis1 dvma_cycles 20217638 dvma_wd_xfr 32815051
10 pcis0 dvma_cycles 482778 dvma_wd_xfr 115046
10 pcis1 dvma_cycles 20989675 dvma_wd_xfr 34068291
15 pcis0 dvma_cycles 482643 dvma_wd_xfr 115069
15 pcis1 dvma_cycles 20834960 dvma_wd_xfr 33817211
bustat’s “-w (instrument PIC to collect statistics) option will program the PCI interconnects PICs (programmable interrupt controller) to collect the statistic passed as an option. These statistics including the number of PIO mode reads and writes, bus throughput, stream transfers, interrupts, and the number of DMA and DVMA operations performed. These counters are documented in the Systems Performance and Tuning book, and can also be viewed by sifting through writing Solaris PCI device drivers for Sun SPARC platforms.
I have had my cat T-bone for close to 13
years, and she has been with me through the many phases and places of my
life. Always chipper and upbeat, her crazy antics are amusing to say the
least.
But, as much as I love her, I seriously hate how much she sheds and the allergies that I have developed while owning a cat. Since I dig my cat and couldn’t bear to get rid of her, I have tried numerous things to reduce the allergens she created. These are the ones that I found the most successful:
I definitely noticed a drastic improvement in my allergies, and my overall health improved significantly. But even with the items listed above, I still noticed a fair amount of fur around my apartment. So…
One of my friends recently tipped me off to the furminator. If you’re not familiar with this thing, you should check it out. It is a pet brush that virtuality eliminates shedding. After a few weeks of use my only response is WOW! Not only does this thing remove mounds of hair from my cat, but I can already see a reduction in the amount of fur that is left on my furniture and rugs. I’m curious to see how this little gem helps with my quest to completely rid myself of cat allergies (or at least the causes), and will make sure to report back once I have a few months of sample data. :)
I have been doing some Redhat and CentOS security research, and came across several AWESOME links on securing Linux installations:
NSA reference guide for securing Linux installations
NSA Guide to securing Linux installations
Stack overflow protection with ExecShield
I recently had to adjust the partition layout on a couple of disk drives. This work occurred on devices with actual data (I made backups before starting), so I needed to be extra careful while performing my work. To ensure that I could recover the data if something went wrong with the partitioning, I made backups of each partition prior to beginning work. Assuming you are using a DOS (MBR) labeled disk, there are two ways to back up the partition table:
To backup a device using option 1, you can use a dd statement similar to the following:
$ dd if=/dev/sda of=/backups/sda.sector0 count=1
To restore the partion table using dd, you can can alter the dd source and destination like so:
$ dd if=/backups/sda.sector0 of=/dev/sda count=1
While this approach works well, I tend to prefer the second method. There are a couple of reasons for this:
To use sfdisk to backup the partition table, you can run sfdisk with the “-d” (dump the partion table in a format that be easily consumed in the future) option and the device to extract the partion table from:
$ sfdisk -d /dev/sda > /backups/sda.ptbl
$ cat /backups/sda.ptbl
# partition table of /dev/sda
unit: sectors
/dev/sda1 : start= 63, size=479987329, Id=83, bootable
/dev/sda2 : start=479987392, size= 8388608, Id=83
/dev/sda3 : start= 0, size= 0, Id= 0
/dev/sda4 : start= 0, size= 0, Id= 0
If for some reason you botch the partition table, you can feed the partion table as input to sfdisk:
$ sfdisk /dev/sda < /backups/sda.ptbl
The second approach has the added benefit that you can review the partition table with a pager while you are making changes, which is especially useful when you grow a LUN and need to use the new space. sfdisk and parted are extremely handy tools, but you should use them with extreme caution! One wrong move can nuke your data, and the author is not responsible for any damage that you may cause to your systems as a result of this post!