Note: This web page was automatically created from a PalmOS "pedit32" memo.

Redhat linux commands

autoscan freshmeat

drbd freshmeat network raid 1

snap for easy video with otherwise unsupported hardware on linux

mii-tool is the old way.  It doesn't work on gigabit networks

ethtool works on 10, 100 and 1000 BaseT

To change the MTU on an RHEL 3 system:
vi /etc/sysconfig/network-scripts/ifcfg-eth*
And add a line like "MTU=9000".  It should take effect on your next reboot.

From Duncan: I've set up a system that allows DCS team members to add and remove hosts to which the RHEL O/S images will be exported to without having to log in to rhn or be root on that system. You can edit the file on's called /auto_install/rhel/export/rhn-hosts. That directory is automounted from rhn.nacs and a cron job runs every 15 minutes starting on the hour to push out the changes.
Registration is a pain because it seems impossible to get around registering using their GUI but if you select 'Tell me why I should register' then 'Can not register at this time' You'll be able to continue through the post-install and then register with the key.
cdrecord -scanbus said 1,0,0, but this was what actually worked on tesuji, with kernel 2.6.7: cdrecord -v -dev ATAPI:0,0,0 securepoint-4.5p3.iso Sometimes this works better (linus' 2.6.7 kernel on FC2, tesuji) : cdrecord -v -dev=ATA:1,0,0 bootcd.iso Try the "-eject" option. :) mkisofs -o cd.iso -hfs -J -r -graft-points pixtosend
tracepath is nice for examining pmtu, but apparently it sometimes lies - because I can see larger frames than tracepath reports going between the hosts in question, through tethereal. screen -r -x should share a screen session nfsstat -o rpc show rpc stats
-bash-2.05b# cat /proc/net/rpc/nfsd rc 1386 1037343 420483406 fh 979922 420473898 0 9497 327249 io 405027549 4193151430 th 12 7859408 122106.880 46341.950 22599.080 36481.660 32597.670 26455.890 9471.830 10035.580 1302.590 13274.840 ra 24 405758114 3293 859 131 55 84 55 17 11 8 82534 net 421522940 421522940 0 0 rpc 421522135 805 805 0 0 proc2 18 811 695 0 0 25344 12 0 0 0 0 0 0 0 0 0 0 863 1680 proc3 22 815 1230508 0 12217802 486762 304 405845161 1037854 2 2 0 0 4 2 2 0 0 559224 48069 14 0 66205 If the th line has large numbers, add more nfsd's - Rajiv Bendale.
Looking for wireless networks: # iwlist scan If you want a continuous monitor (more sophisticated) look into "kismet" iwconfig
Slow down rate of linux software raid resync after disk failure and replacement: > reduce the numbers in: > /proc/sys/dev/raid/speed_limit_max > /proc/sys/dev/raid/speed_limit_min
From a guy on oclug: For best bet on compatibility with Linux go with a Prism based card. 802.11b will be PrismII or PrismIII, and 802.11g will be PrismGT.
cat /proc/fs/nfs/exports
On getting good performance out of synchronous NFS: The best way to get good nfs performance with a sync export is to use a data-journalling filesystem, and have the journal somewhere fast. I use ext3. I believe that some other filesystems support data journalling, but I don't know the details. An ext3 filesystem exported with "data=journal" is significantly faster that with the default "data=ordered". With ext3, it also helps to export with the "no_wdelay" export option. I'm not entirely sure why this helps, and I haven't confirmed that it is still the case (I discovered this at least 2 years ago) but it is worth checking in your environment. Ext3 supports having the journal on a separate device. If you put it on a fast device, you will get faster response. One option is to buy an NV-RAM card and put the journal on that. is one supplier that I know of. There are doubtlessly others. Another option is to put it on a separate drive, or preferably a separate mirrored pair. As journal writes are sequential, you won't suffer seek time on the journal device and it will be quite fast. My typical fileserver configuration is to have a pair of small (36gig is the smallest I can easily get) 15K SCSI drives as a mirrored pair, and to put root, swap, and a journal partition on this. Then a separate box contains a dozen or so drives of whatever size I want in a raid5 configuration. The ext3 filesystem is on the raid5 array, the journal is on the mirrored pair with root and swap. There is almost no IO to root and swap, so the journal gets the drives almost to itself. This configuration is adequately fast. NeilBrown
> You will need to stop Evolution backend tasks and the GConf daemon > before copying your data. On *both* machines (syncing the data to disk > on the source machine and not using old data on target machine): > > $ evolution --force-shutdown > $ gconftools-2 --shutdown Doh! Make that 'gconftool-2'. Sorry for any confusion this might have caused... ...guenther
iptstate is pretty cool. It should current iptables-related connections, apparently. It comes with FC3 and Devil Linux 1.2, but not FC2 or RHEL 3.
On migrating linux NFS servers: Yes - existing clients will still use the 'default' filehandle type. Any new clients will use the fsid= option type. You have to make sure all clients have remounted the file systems before moving the disks to a new host. James Pearson David Dougall wrote: > So, you are saying that if I add an fsid= option into the exports, the > server will work with both that filehandle and the default major/minor > number one? > --David Dougall > > > On Mon, 13 Dec 2004, James Pearson wrote: > > >>David Dougall wrote: >> >>>I am moving filesystems/disks to new NFS servers. They are going to >>>change major and minor numbers. Is there any way I can prevent stale >>>mounts with the fsid= option in the exports? >>>I have tried this on a test environment, but when I try to create an fsid= >>>option, it completely changes the filehandle format in the nfs packet. Am >>>I missing something, or are the default and forced fsid options >>>incompatible? >> >>I believe using the fsid= option does use a different file handle id >>type, so you can't directly do what you want with the fsid option. >> >>However, you can re-export a file system with an added fsid= option - >>any existing mounts will still use the 'previous' file handle type based >>on the device id, but new mounts will use the new fsid file handle. You >>then will have to make sure all existing clients remount the file system >>before moving the disks. >> >>I've done this before - but I had to make the export change well in >>advance, so that I could make sure all existing clients remounted the >>file system before the move. >> >>James Pearson
I would start by turning on the RPC debugging: Try sysctl -w sunrpc.rpc_debug=3 (or "echo 3 >/proc/sys/sunrpc/rpc_debug" - which does the same thing). The first thing to do is to look for "RPC: %4d received reply" and try to match the pid to the request pid. Also look for timeouts. > what are the other possible debug settings besides '3' > ?? See the RPCDBG_* values in include/linux/sunrpc/debug.h: they define the bitmask of "dprintk()"s that can be turned on.
udevinfo -a -p (dir) helpful in constructing /dev entries
From Duncan: We've updated the certificate for RHN so you'll need to run the following if your system isn't checking in: rpm -e rhns-ca-cert-1.0-1 rpm -i
Backing up gconf2: gconftool-2 --dump
Shutting down gconf2: gconftool-2 --shutdown
Firstly, you should always use the '-c' flag when measuring NFS client performance. Otherwise, you are basically just measuring the speed with which your machine can write to the local page cache (which may indeed explain your "knee" at 1MB here - that would be where the client starts to force a flush to disk).
Installing grub on a hard disk: # grub Grub>device (hd0) /dev/sdb (/dev/hdb for ide) Grub>root (hd0,0) and then: Grub>setup (hd0) Also: grub-install /dev/sda
Blocking a host with iptables: iptables -A INPUT -s -j DROP
On manipulating source rpm's: See which includes rpmdiff A script which allows you to do a diff on 2 similiar source rpms. rpmextract A wrapper around rpm2cpio for extracting the contents of a src rpm. rpmpatch For patching an old src rpm to provide a new src rpm.
I moved my home directory from /Dcs/staff/strombrg to /Dcs/seki/strombrg. Evolution lost track of where its addressbook was. I was able to fix it by going into gconf-editor, and editing apps/evolution/addressbook. There was a value that had memorized a hard path to addressbook in my old home directory. Also had to vi my .gtkrc to change the hard path...
Perhaps why we get stale handles on reboots: On 2.4 kernels it is not 'ornamental' - if the server reboots without an entry for a client mount in /var/lib/nfs/rmtab, then the client will get a stale NFS file handle when the server reboots. This can happen if umount fails e.g. the mount point is busy - rpc.mountd on the server removes the entry from /var/lib/nfs/rmtab, but umount fails, so the file system remains mounted.
"A CPU chip containing multiple hyper-threaded processing elements is counted as a single CPU"
> Normally, on a RHEL system, you just go into /user/share/ssl/certs/ and > > type: > > make whatever.pem go to /usr/local/share/doc/dovecot (on FreeBSD), edit example dovecot-openssl.cnf for your needs and run
From Duncan, 2005-03-03: In order to eliminate the redundancy inherent in providing a separate package for the kernel source code when that source code already exists in the kernel's .src.rpm file, Red Hat Enterprise Linux 4 no longer includes the kernel-source package. Users that require access to the kernel sources can find them in the kernel .src.rpm file. To create an exploded source tree from this file, perform the following steps (note that <version> refers to the version specification for your currently-running kernel): 1. Obtain the kernel-<version>.src.rpm file from one of the following sources: o The SRPMS directory on the appropriate "SRPMS" CD iso image o The FTP site where you got the kernel package o By running the following command: up2date --get-source kernel 2. Install kernel-<version>.src.rpm (given the default RPM configuration, the files this package contains will be written to /usr/src/redhat/) 3. Change directory to /usr/src/redhat/SPECS/, and issue the following command: rpmbuild -bp --target=<arch> kernel.spec (Where <arch> is the desired target architecture.) On a default RPM configuration, the kernel tree will be located in /usr/src/redhat/BUILD/. 4. In resulting tree, the configurations for the specific kernels shipped in Red Hat Enterprise Linux 4 are in the /configs/ directory. For example, the i686 SMP configuration file is named /configs/kernel-<version>-i686-smp.config. Issue the following command to place the desired configuration file in the proper place for building: cp <desired-file> ./.config 5. Issue the following command: make oldconfig You can then proceed as usual. Note An exploded source tree is not required to build kernel modules against the currently in-use kernel. For example, to build the foo.ko module, create the following file (named Makefile) in the directory containing the foo.c file: obj-m := foo.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) default: $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules Issue the make command to build the foo.ko module.
FWIW Red Hat appears to officially support 8TB ext3 filesystems on Red Hat Enterprise Linux 4: "Ext3 scalability: Dynamic file system expansion and file system sizes up to 8TB are now supported."
From Duncan: RHEL 4 installs with a default setting that rejects remote connections to the local X server despite the xhost or mxconns settings. To turn this behavior off, edit /etc/X11/gdm/gdm.conf and make sure this DisallowTCP is set to false.
Nice talk that covers the relationships between different RAID/Volume management software
On speeding up huge ext3 directories: [Look for feature "dir_index" on the "Filesystem features:" line in "/sbin/tune2fs -l <device>" output.]

Back to Dan's palm memos