Stuff worth safe keeping, in case I need it in the future, I know where to look
Well, I’m sitting again here grinding my head on how to fix up a certain package. Now, I had to look it up again, so this time I’m writing it down!
|
1 2 3 |
Source1: ${name}.initd ... install -o root -g root -m 755 %{S:1} $RPM_BUILD_ROOT/etc/init.d/ndo2db |
Well, the title is kinda misleading since you need administrator privileges to run msconfig in it’s full scope. But this is just a hint to myself on how to execute msconfig without logging out and then logging in as administrator.
|
1 |
runas /user:Administrator C:WINDOWSpchealthhelpctrbinariesmsconfig.exe |
In the past, I always had problems with SLES and our Tivoli Storage Manager client’s when backing up files with german umlauts. Well, today I looked a bit harder, and quite quickly found a solution.
|
1 2 |
sles9 root [0] > env | grep ^LC LC_CTYPE=de_DE.UTF-8 |
As you can see from the above, SLES9/10 ain’t setting LANG or LC_ALL (which I searched for first), but is setting LC_CTYPE.
So, simply changing the LC_CTYPE in the init-script and/or prepending the dsmc command line with a new LC_CTYPE fixes my umlauts problems!
|
1 |
sles9 root [0] > LC_CTYPE="en_US" dsmc incr |
Well, I had a long’ish talk with one of my trustworthy IBM senior consultants the day after writing this …
He told me something along the lines of this:
If you would like to back up files with names containing characters with a code > 127 please ensure that you have chosen a SBCS character set for your locale. The default code page C or the code page POSIX supports characters up to 127 only. Files whose names contain special characters will be skipped if C or POSIX is used. It is strongly recommended to perform a system backup by using a SBCS character set to prevent any file or directory from being skipped. This behavior for different locales is intended.
And this:
The UTF-8 locale is default on some Linux platforms. However, TSM Client currently does not support running under UTF-8 locales (such as en_US.UTF-8 and ja_JP.UTF-8). Export your LANG and LC_ALL environment variables to the iso8859-1 or EUC versions of your locale and then start a new xterm (or mlterm) session prior to running TSM Client.
That basically means, at least for using the TSM Client Java Interface (dsmj) and the scheduler/client acceptor daemon you have to switch your locales to something _not_ UTF-8 capable.
He also mentioned, that IBM doesn’t have a real solution for this problem, as well that there is no real workaround. You need to invest some time into figuring out the “right” locale setting for your system(s), since after writing the above I came to the result that it ain’t enough ..
You need to do the following:
|
1 2 3 4 |
lang="de_DE@euro" export LC_CTYPE="$lang" export LANG="$lang" export LC_ALL="$lang" |
After doing so, the scheduler and the command-line client works …
Well, most of you already know that I’m a Nagios fanatic. I like to watch as many aspects as I possibly can. So, yesterday I started figuring out ways to watch our different cluster groups (housing a bunch — try above 20.000 — of file shares).
Now, my first tries failed horribly. I brought down a complete cluster group, resulting in a major annoyance. Now, today I went at it a bit smarter 😛 I cloned myself two VM’s off my Windows Server 2003 Enterprise R2 template, created a new cluster.
After that, I tried it on the test cluster again, same result. The resource is successfully created, but once I try to take it online, it breaks and moves the whole cluster group to the other node (as cyclic moving between the cluster nodes with no end).
After that, I figured something has to be wrong with the command I’m trying to use, the one as instructed by the NSClient++ wiki. I then tried the command on the command line, but as soon as hitting <TAB> (oooold bash habit 😛 ), it completed the path, but put quotes around it … Don’t ask me.
If I try the path without the quotes, no-joy at all. Once you put quotes around it, everything becomes honky-dory and the resource comes online without the slightest trouble!
Hint to self: When creating a NSClient++ cluster resource (or any application resource using a command that needs switches for that matter), use a quoted command line along the lines of this:
|
1 |
"Q:_nsclientnsclient.exe" /test |
You know, I’m not getting any younger. It’s getting harder remembering every damn command … so here is how you get information out of your EXT3 filesystem:
|
1 2 3 4 5 6 7 8 9 10 |
sles10sp2 ~ [0] > tune2fs -l /dev/sda2 | grep "^Filesystem" Filesystem volume name: <none> Filesystem UUID: 8eec8235-4d9e-4b58-acf9-3c68c977d5ea Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal resize_inode filetype needs_recovery sparse_super large_file Filesystem state: clean Filesystem OS type: Linux Filesystem created: Tue May 27 10:48:56 2008 |
For people, who are as click and point-lazy as me, here is how you restart the service without using the service management applet.
|
1 2 |
net stop "NSClientpp (Nagios) 0.3.5.2 2008-09-24 w32" net start "NSClientpp (Nagios) 0.3.5.2 2008-09-24 w32" |
Well, since I had to brood about this (again I might add), I’m gonna write it down this time …
Setting up the InnoDB raw device isn’t that hard, just make sure the device has proper permissions (either add mysql to the disk group or create a udev rule).
|
1 |
KERNEL="sdb2", OWNER="mysql", GROUP="mysql" |
Now after that (and a reboot/udevcontrol reload_rules later), you should be able to initialize the InnoDB device. Yes, the InnoDB device needs initializing.
When you create a new data file, you must put the keyword newraw immediately after the data file size in innodb_data_file_path.
The next time you start the server, InnoDB notices the newraw keyword and initializes the new partition.
After that is done, you should be able to start the MySQL service for the first time. It is gonna fail (at least according to the init-script), but ultimatly if you take a closer look at /var/log/mysqld.log it’s gonna be successful.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
14:11:07 InnoDB: Setting file /dev/sdb2 size to 50200 MB InnoDB: Database physically writes the file full: wait... InnoDB: Progress in MB: 100 200 300 400 500 600 700 800 900 1000 ... 50200 14:21:26 InnoDB: Log file ib_logfile0 did not exist: new to be created InnoDB: Setting log file /var/lib/mysql/db/ib_logfile0 size to 512 MB InnoDB: Database physically writes the file full: wait... InnoDB: Progress in MB: 100 200 300 400 500 14:21:34 InnoDB: Log file ib_logfile1 did not exist: new to be created InnoDB: Setting log file ib_logfile1 size to 512 MB InnoDB: Database physically writes the file full: wait... InnoDB: Progress in MB: 100 200 300 400 500 InnoDB: Doublewrite buffer not found: creating new InnoDB: Doublewrite buffer created InnoDB: Creating foreign key constraint system tables InnoDB: Foreign key constraint system tables created 14:21:42 InnoDB: Started; log sequence number 0 0 |
After that, remove the “newraw” from your /etc/my.cnf. Otherwise, MySQL is gonna reinitialize the volume all over again, as the handbook states.
However, do not create or change any InnoDB tables yet. Otherwise, when you next restart the server, InnoDB reinitializes the partition and your changes are lost.
After InnoDB has initialized the new partition, stop the server, change newraw in the data file specification to raw.
Today I ended up working out the details on what we want to monitor regarding our BladeCenter. The most interesting details (for us that is) are these:
It wasn’t *that* hard to implement. Only trouble(s) I ran into, were (1) IBM did a real shitty job with the MIB’s. If you look closely into the mmblade.mib, you’re gonna notice, that not a single OID is specified for the events. (2) As the MIB’s weren’t documented anywhere, I had to look them up via snmpwalk (which I had never used before). So as a reminder (to myself), here’s how it is done:
|
1 |
snmpwalk -v1 -c public -O n 10.0.0.35 .1.3.6.1.4.1.2.3.51.2.2 |
This will get you a list, with a lot of output (5154 lines to be exact). Lucky me, the web interface of the management module/ssh interface is rather verbose, so all you need to do is compare those values with what you are looking for.
So for myself (and anyone interested) read ahead for the list of checks we are currently running on the management module. Read More
In our current fight against the BladeCenter switches, we’re currently facing the problem that the blades ain’t able to send/receive DHCP-traffic.
So in order to move forward, we had to use static IP addresses. And since SLES10 ain’t straight forward on that, I had to look it up. Now, here’s for me (and everyone else tired of searching) how to do it:
|
1 2 3 4 5 6 7 8 9 |
install=http://ftp.barfoo.org/install/SLES10-x64/CD1 netdevice=eth0 hostip=10.0.1.240 netmask=255.255.255.0 gateway=10.0.1.1 nameserver=10.0.1.2 domain=home.barfoo.org insmod=bnx2 splash=verbose |
As I did some switching today (between the new lin_tape version by IBM and our own lin_tape version), I ended up writing those lines a dozen times. Here is (just for me, if you don’t care .. skip ahead) on how to generate a list of commands:
|
1 2 3 4 5 6 |
for i in $( seq -w 1 32 ); do token="${i/0/}" path_prefix="/dev/lt/IBMtape12245775" echo "DELETE PATH TSM1 VTL1_DR$i SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL1" echo "DEFINE PATH TSM1 VTL1_DR$i SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL1 DEVICE=$path_prefix$((token+11))A1" done |
which should get you a list like this:
|
1 2 3 4 |
... DELETE PATH TSM1 VTL1_DR21 SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL1 DEFINE PATH TSM1 VTL1_DR21 SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL1 DEVICE=/dev/lt/IBMtape1224577532A1 ... |