Posted by Ceri Davies
Sun, 09 Oct 2005 17:23:00 GMT
When I ask Stef if she wants a cup of tea or coffee, she’ll often say “yes, peppermint please”, and I’ll mutter ”EINVAL” to myself and chuckle. That’s really nothing compared to what I found myself doing today.
We were walking round H&M earlier and she said “look for things that are brown or pink” (hey, no smirking in the back) and I actually said “your search returned 45000216 results; try narrowing your search by specifying additional keywords”.
I’m not sure whether I’m more upset by the look she gave me, or that I was a factor of ten out.
Posted in General | no comments | no trackbacks
Posted by Ceri Davies
Wed, 05 Oct 2005 22:06:00 GMT
Jeremie Le Hen followed up the locked accounts stuff and had *LOCKED* committed to the portable OpenSSH tree. Those patches to cron(8) that I posted do not work, so now I have to earn my bullshit by fixing them. Misery.
I also did some work with netgraph(4), netflow and rrdtool this week which I’m still finishing off. My netgraph setup is reasonably simple but includes divert(4) sockets and ipfw(4) so may be of interest to others. Once I have the setup finalised I’ll document it here.
Emily Boyd’s redesign also spent a day or two being merged to the main site this week; murray, simon and hrs seemed to do most of the heavy lifting, so thanks to them and Emily. There are still a number of people crowing that they don’t like it, but now we can just ask them to submit a new stylesheet, and there’s no news sweeter than that.
Posted in FreeBSD | no comments | no trackbacks
Posted by Ceri Davies
Mon, 03 Oct 2005 19:47:00 GMT
My foray into Oracle continues; today I got to see the horrors of the DBMS_JOB package, which is used for scheduling periodic tasks (think cron(8)).
This particular database had a couple of jobs scheduled, but they were not being run. I knew how to sort that out; in 9i there is a database parameter called job_queue_processes which governs how many job runners are allowed concurrently, and this was set to zero:
SQL> show parameters job
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
job_queue_processes integer 0
There were, therefore, no job runners:
SQL> !ps -ef|grep j
oracle 6183 6182 0 14:13:15 pts/1 0:00 grep j
oracle 6182 6166 0 14:13:15 pts/1 0:00 /bin/sh -c ps -ef|grep j
This is a dynamic parameter, so I changed it:
SQL> alter system set job_queue_processes = 2;
System altered.
SQL> !ps -ef|grep j
oracle 6226 6166 0 14:17:35 pts/1 0:00 /bin/sh -c ps -ef|grep j
oracle 6219 1 0 14:17:30 ? 0:00 ora_cjq0_WXYZ
oracle 6220 1 0 14:17:30 ? 0:00 ora_j000_WXYZ
oracle 6222 1 0 14:17:30 ? 0:00 ora_j001_WXYZ
Since there were jobs that needed running, the ora_cjq controller instantly fired off a pair of ora_jnnn processes to run them. Unfortunately, one of them was an analyze of the SYS schema, which immediately caused deadlocks since this was the middle of the day. And this despite the job not being scheduled until what I thought was 3am:
SQL> select job,last_date,next_date,
substr(interval,1,24) interval,
substr(what,1,48) what
from dba_jobs
where job = '2';
JOB LAST_DATE NEXT_DATE INTERVAL WHAT
--- --------- --------- ------------------------ ------------------------------------------------
2 03-OCT-05 17-OCT-05 trunc(sysdate+14)+27/24 dbms_utility.analyze_schema('SYS','COMPUTE');
However, Oracle insisted on playing catchup there and then, which made me doubt whether trunc(sysdate+14)+27/24 really did mean “14 days from now at 3am”.
Unfortunately the docs suck big time; the definition of INTERVAL doesn’t exist in the Oracle9i Database Administrator’s Guide, and the excerpt below tells you everything you need to know in order to understand my pain (my emphasis):
If you always want to automatically execute a job at a specific time, regardless of the last execution (for example, every Monday), […]
It just strikes me that “Monday” isn’t all that specific…
Posted in Oracle | 1 comment | no trackbacks
Posted by Ceri Davies
Sat, 01 Oct 2005 14:34:00 GMT
I went up this morning to check out the new plot, and it’s not looking too bad:
The shed needs a new door and wall, but it’s structually sound and the roof is in good condition. Unfortunately, that’s dock that you see growing around it, but the couple on the plot next door (on the left of the fence in the picture above) have covered most of it with plastic so I at least have somewhere to start without having to clear the whole plot (which had been my original plan, but I’m so glad it’s not necessary).
The only worry I have is that I’m unsure of the boundaries of this plot; the corner markers by the shed are clear enough but at the far end they don’t seem to exist. There are a pair of yellow ones on the plot next door but they are 18 inches apart (indicating that they delineate the mandatory path between plots), whilst the boundary at the back of this plot is supposed to be 2 metres. The fact that this is a 9 perch plot rather than the usual 10 doesn’t help to clear the confusion. I’ll have to go up with a measuring tape to get sizes for the shed, so I can work it out then.
Posted in Gardening | 6 comments | no trackbacks
Posted by Ceri Davies
Wed, 28 Sep 2005 20:52:09 GMT
I got a new 9-perch allotment with a broken shed on. Have yet to check it out with owner’s eyes, but it looks good based on times I’ve been past it and there is a water trough going in right next to it in the near future.
Once I get up there I’ll take some photos and see what I have to deal with over the next month…
Posted in Gardening | no comments | no trackbacks
Posted by Ceri Davies
Tue, 27 Sep 2005 18:41:00 GMT
Turns out that the bug I reported yesterday is in my dumb head and not with lighttpd at all. Doh.
Update: Work agreed to pay for part of my EuroBSDCon trip. That is so cool of them, even more so since I have only been here for three weeks.
Posted in FreeBSD | no comments | no trackbacks
Posted by Ceri Davies
Sun, 25 Sep 2005 23:59:00 GMT
I finally got rid of my last FreeBSD 4.x machine; this very web server has been upgraded to 6.0-BETA5 today.
The whole process took about 9 hours, including backups; this is a very slow machine and I installed a whole bunch of apps from ports rather than packages (and I was being extra paranoid since this is also my mail server).
The one snag is that I couldn’t install the textproc/docproj port due to breakage in textproc/docbook-xsl, but I’ll survive (or install it from packages).
Found a bug in www/lighttpd’s start-up script along the way; PR filed, but there has to be a nicer way of dealing with this than my “fix”. Still, after 9 hours at this desk I’m not looking for it right now.
Posted in FreeBSD | no comments | no trackbacks
Posted by Ceri Davies
Fri, 23 Sep 2005 12:01:00 GMT
In my new job, I’ve inherited the dubious pleasure of babysitting some Oracle 9i databases. Though I am somewhat familiar with Oracle, I really only know enough to know that I don’t know enough, so when I wanted to see where all the space was going, having already identified the tablespace that I was interested in, I issued the following, perhaps naive, statement:
SELECT segment_name, segment_type, bytes/1024/1024 MB
FROM dba_segments
WHERE tablespace_name = 'WIBBLE_DATA'
ORDER BY bytes;
That turned out to be a lot of typing for something that I wanted to do a lot, so I decided to throw it in a script, named segmentsbytablespace.sql (yes, that *is* quite a long file name – your point?). The next logical step was obviously to parameterise the tablespace name. I simply cannot believe the can of worms that this opened.
If you’ve run a script in SQL*Plus before, you’ll probably know that arguments to scripts can be accessed by the positional parameters &1, &2, …, &n. So the script just becomes:
SELECT segment_name, segment_type, bytes/1024/1024 MB
FROM dba_segments
WHERE tablespace_name = '&1'
ORDER BY bytes
/
and is run like this:
SQL> @segmentsbytablespace WIBBLE_DATA
That would be too easy; there are a couple of problems with this.
The first is simply that if you leave out the parameter, SQL*Plus prompts you for its value, like this:
SQL> @segmentsbytablespace
Enter value for 1:
Enter value for what now? I’d like it to say Enter value for tablespace. It looks like it is impossible for me to do that (unless I throw that variable at the database server and ask if it is NULL or not; I’m not doing that). This issue is, at least, cosmetic.
The second problem is that running the script with an argument defines the same argument for the next invocation, i.e. in this example:
SQL> @segmentsbytablespace WIBBLE_DATA
SQL> @segmentsbytablespace
both scripts believe that they have been passed WIBBLE_DATA as an argument. I have to explicitly undefine the positional parameter 1 at the end of my script to avoid inadvertently passing it to another script executed in the same session.
For those who know SQL*Plus, you also benefit from this “feature” if you use the &&1 form of variable dereferencing in order to avoid prompting your users for the same value more than once.
Perhaps I missed something, but this is documented behaviour and looks like an accident waiting to happen to me.
Posted in Oracle | no comments | no trackbacks
Posted by Ceri Davies
Tue, 20 Sep 2005 21:00:00 GMT
An old discussion that we had in PR 71147 cropped up again on cvs-src after keramida made a commit to passwd.5 regarding the use of * in master.passwd to “lock” accounts.
I pointed out that Solaris has possibly the best model for this, with it’s use of *NP* and *LK* for various degrees of “locked”:
Solaris uses the string *NP* to
indicate that a user has no
password - password authentication is
therefore disabled for that user,
disallowing su, password-based ssh
access, etc. Cron jobs, key-based
auth, etc. continue to work. It also supports *LK* which indicates that
an account is locked: in this case, cron jobs for the user will not be
run and ssh access is denied altogether.
The ssh bit works because OpenSSH
knows that it should be looking for
the string *LK* and denying access if
it is there. Search for
LOCKED_PASSWD_STRING in
src/crypto/openssh/auth.c.
See http://lists.freebsd.org/pipermail/cvs-src/2005-September/thread.html#52572 for the full thread.
I asked again why OpenSSH doesn’t look for *LOCKED* on FreeBSD, and des has kindly offered to look into adding it.
In the spirit of having real locked accounts, I’ve knocked up a patch for cron(8) that checks for the string ”*LOCKED*” in the pw_passwd field of the struct pw returned by getpwnam(3) and am looking for testers. I haven’t done a shred of testing myself due to a lack of machines running anything recent but if you feel brave, please check it out. The latest version will always be at http://people.FreeBSD.org/~ceri/cron.diff.
Posted in FreeBSD | 2 comments
Posted by Ceri Davies
Tue, 20 Sep 2005 20:02:00 GMT
I’ve decided to move the web log to Typo, purely so that I can stop running MySQL (because it keeps spinning on EAGAIN on some pipe or other), the worst excuse for a database I ever came across.
The process of doing so has only confirmed that I am doing the right thing; for example, you’d think that the --compatible=postgresql or even the --compatible=ansi options to mysqldump would produce SQL that PostgreSQL would understand. No. All that does is leave out the MySQL-specific storage clauses and quote things with with real quotes rather than backticks. The data types are not converted into something that PostgreSQL understands.
For example, PostgreSQL doesn’t understand int(n) as a datatype; integer is what it wants to see. --compatible=postgresql doesn’t know that for some reason. I count that as pretty basic.
Anyway, the point is that for now, all the articles have not been moved. They will be, I just have to work out the best way of doing it. For now, old web log is at http://submonkey.net/wordpress/ and the new one is at http://typo.submonkey.net/.
The gardening news is that I finally got hold of the site supervisor and I’ll be picking my new plot next Wednesday.
Update, 20/09, 22:48: Turned out to be easier to migrate all the posts by hand. Some comments were lost but I’m not bothered.
Posted in Gardening, General, Software | 2 comments
