I came across this a while back: a wonderfully informative technical blog post on tracking down a slowdown in Windows.
Here's hoping I never need this: a Tcl script that allows you to use Emacs as an editor for Outlook.
Today I installed Windows 7 Pro on a Macbook Pro with Boot Camp. I ran into two problems I figured I should document:
First, Boot Camp would not proceed past the offer to burn a CD with drivers for the disk. It's a bug, and I was able to ignore it without problems; the networking and graphics came up w/o problems.
Second, after installing Windows Defender and rebooting, Windows would freeze at the login screen. This too is a known problem, with lots of suggestions on how to fix it. What worked for me was booting into safe mode w/the command prompt (every other safe mode would freeze), then disabling the Windows Defender service with MMC. After that, I was able to boot; after that, I was able to set it to "Automatic Start", reboot, and I've had no further troubles.
Six books from O'Reilly on Windows Server 2003 (Cookbook, Security Cookbook, In A Nutshell, Netowrk Administration, Securing, and Learning) and there was ONE mention of SNMP in the indexes. What the hell?
Looks like we're going to be getting a bunch more Windows desktops in the near future at $WORK, so I've been looking into Unattended again. I'm having much better luck this time than the last time I tried, a couple or three years ago.
I can't remember what went wrong then, but this time it took me a
stupidly long time to figure out that an error message about a
missing djgpp.env file means you forgot to unzip the support
files under a directory called djgpp.
Another thing that tripped me up this time: unattended installations from OEM media are not allowed by default, even with a legit key from the sticker on the side of your new shiny box. This mailing list post pointed out the magic key, which seems to be working for mwe.
Now that I got those things sorted out, things are going much better.
I'll be damned: a GPL'd Windows Eventlog-to-syslogd interface. Thanks to Will for the pointer!
I was able to get Quickbooks 2007 working with a non-admin account today…woot! Here's what I did:
This isn't ideal — the explorer process in QB is still running privileged — but at least that's the only IE process running as admin.
And Bacula: tripped over a small thing. I'm running the btape utility to make sure our tape drive works with it. I ran bfill, rather than fill, then wondered why I got errors at the end. Turns out to be an old command that probably shouldn't be around anymore.
Now to run fill…another couple hours to go.
Some fun Emacs stuff:
I had a meeting with my boss at work last week (before a nice four-day weekend…the split schedule I've got means that sort of thing happens very rarely. But I digress) to set my priorities now that the upgrade has more or less been finished (lingering issues aside; see ahead).
One of the big things is getting Zimbra set up. This will be nice; we do not have a calendar for the office right now, and this is is getting to be a pain. My boss is open to the idea of something that's not Outlook/Exchange, and that's good.
The other thing is getting a bunch more Windows machines in. This is a small shop, so "a bunch" means another 15 or 20 -- which'll double the number we have. I'm not entirely happy about that, but because this is a longer-term project I've been given time to do this right. And to me, "right" means "using open-source tools whenever possible to manage Windows". Thus, I'll be getting the time to set up Unattended and wpkg, and possibly even digging up Windflower and seeing if it's worth continuing. I'm actually kind of excited about this.
It's a little strange having a manager take this much of a hand in setting priorities; I've worked in a series of small shops and, up 'til now, have been left more or less on my own nearly the whole time. It does feel good to get a bit of direction, though. I mean, I know what needs to be done and I'm doing it, but I've always felt a bit lost trying to decide what's most important for everyone once past the finger-in-the-dike stage.
Now to go try and get Multi-TTY working on this laptop…
Ack: Just realized I never described the lingering problems with
Solaris 10. Fairly simple to describe: LDAP lookups take 'way longer
than they should (ls -l /home/ can take 5 seconds per line
sometimes), and JDS on the SunRays is slower in parts than it should
be (click on the logout button, wait 60 seconds, message pops up
saying "Are you shure you want to log out?"). I'm hopeful I can track
those down without too much effort…
I can't believe it's taken me three years to find this entry from
Aaron Margosis' blog about how to run Windows or Internet Explorer as
admin using runas. I've always cheated by running different .cpl
files until I found something that'd launch IE, then forget what it
was and curse myself for not writing it down. Anyhow, this allowed me
to open up C:\Program Files\Mozilla Firefox for modification by
selected users, which in turn allows FF's auto-update feature to work
without me having to wake up.
Also: Can't believe I never knew about mutt's T command. Nice.
Actually, I shouldn't complain about that last one; MS actually uses Portage. Who knew?
This is going to be a long story, but I hope it'll be instructive. Bear with me.
Back at my last job, we had a Samba server, running on FreeBSD, acting as a Primary Domain Controller for around 35 W2K machines. The same machine also acted as NIS master for a similar number of FreeBSD machines. It also did printing, mail, DNS, and half a dozen other things. This machine was getting old; it's CPU usage was often pegged by a large print job, it was running out of disk space, and I was beginning to be worried about the inevitable day of death. I began planning for the upgrade: a new machine, faster and bigger hard drives, more memory and gigabit ethernet for the day we all moved to GigE. Oh, and rack-mounted...definitely rack-mounted.
The opportunity was taken to upgrade much of the software on the machine, including Samba. I decided to move from 2.2 to the 3.0 series; the speed differences seemed pretty impressive. I also wanted to get as many of the big upgrades done at once as possible: the prospect of going through the upgrade repeatedly did not appeal.
Of all the upgrades I was doing, Samba made me the most nervous. I read through the excellent (and Free) Samba HOWTO and made notes: how to move to the tdsam password database, changes in configuration options, and so on. I had the new server for a while, so I was able to run through many tests: getting a Windows machine to log on, DNS queries, and so on.
Finally, the big day came. I went in on a Saturday and made the move. Most of the rest of the day was spent testing, chasing down the inevitable mistakes, and testing some more. I tested by logging into machines after they'd joined the domain, and making sure that everyone could still log into their workstations. All told, things went pretty damned well, and I congratulated myself on a job well done.
Later though, a few things began to crop up that I haven't been able to explain. I could no longer add new domain accounts to SSH under Cygwin. A shared printer wasn't being shared any longer. In fact, shares weren't working at all. I banged my head against this for a while, but since the problems were pretty erratic they tended to fall to the wayside in favour of explaining, one more time, why the words "spare computer" were self-contradictory.
Finally, though, I put some more time into it. And it's a little hairy, especially for this Unix guy, so bear with me.
(Incidentally, I couldn't have figured out half of this without the help of Clarence Lee, a co-op student working with us. Sure, he uses IIS, but he firewalls it with OpenBSD and he got an internship at Microsoft. He's a good guy.)
The shared printer: could not figure out what was going on here. Guy
who had it could print to it, no problem. Used to work for everyone,
no problem. Now it wouldn't work. Broke the problem down to the point
where I was using smbclient on FreeBSD, or net view on W2K, to try
and list the shares, and that didn't work. Not any of them -- not
IPC$ or anything. I was fairly sure this wasn't supposed to be
happening.
There was a machine in limbo (not the same as spare, thenk yew!) while a coop student became permanent. I got it using the other networked printer, and tried sharing it. Again, command-line utilities would simply not list the shares. What's more, when I tried getting other people to log into the machine (I was fairly irritated at this point, and not at my most rational), they couldn't log in. WTF? I could log in, and there had been no complaints from the person whose machine it had been.In a moment of irritation, I got the test machine to rejoin the domain...and suddenly, everything was working: I could list shares on it, other people could list shares on it, people could log in, and everything. Yay! It's so simple! Rejoin the domain! Everything will be great!
Ha! It is to laugh. Profiles were not coming in when people logged
in. My Documents was empty, they got that stupid, evil, vile "Let's
take a tour of Windows! And let me help you set up your network! DO
IT!" popup window. I couldn't figure it out.
Clarence and I banged out heads against it some more, and finally came to a conclusion.
When you migrate Samba, you're meant to take the old SID with you
using net(8) GETLOCALSID and SETLOCALSID. The SID is meant to
be a world-unique string/number that identifies a domain, or an
account -- think something like the DN in LDAP, or NIS domainname +
UID in Unix. (A user's SID has a part that belongs to the domain, and
another, smaller part that is unique to that user.) I didn't do that
-- screwup -- and so the Samba server had generated a new SID. As far
as Windows is concerned, the identity of your domain is solely
determined by the SID; the name is their just for your
convenience. (Insert snide remark here about how magic invisible
numbers have no business being that important.)
As a result, the machines that were present at the migration didn't know where their Primary Domain Controller (PDC-- the machine officially in charge of the domain) had gone, and were running on cached credentials, profiles and so on. (This is the same thing that allows you to log into a Windows laptop that belongs to a domain, even when you've taken it home and aren't able to reach your PDC any more.) Printing and shared resources from the Samba server continued to run because of open permissions or credentials (ie, user name and password) that don't depend on SIDs.
This also explained why I could log into the machines without problems: because, as sysadmin, I'd logged into all of them before to do maintenance. My credentials were cached, so the machines were able to authenticate me w/o consulting with their (now missing) PDC. And of course, everyone was able to log into their own workstations for the same reason.
So: machine rejoins the domain and people can log in, because now the
machine can find its PDC and verify their passwords. But profiles
aren't showing up because the profile's NTUSER.DAT -- the user's
hive, loaded into the registry at HKEY_CURRENT_USER when they log in
-- belonged to/was marked with/was owned by the account's old SID,
and Windows refused to load it and lots of stuff broke or was missing.
After some more searching, I finally figured out the way around this.
First, you need to use the profiles(1) tool in Samba to change
the SID on NTUSER.DAT, which'll be wherever Samba keeps
profiles. You should check their SID in Samba by using
pdbedit(8), though odds are the user ID/group ID part will have
remained the same.
Second, you need to take care of the profile. There are a few ways of
doing this. The easiest way is to copy the modified NTUSER.DAT to
their profile directory, then log into the machine as Administrator
and join the new domain, then get the user to log in. Their profile
will be copied over, just as if they'd logged into a machine for the
first time. However, this can cause problems with certain programs who
haven't been informed about the change.
To illustrate: if the domain name is named EXAMPLE, and the user
account is jdoe, then their profile will usually be at C:\Documents
and Settings\jdoe (let's just call that D&S\jdoe for
short). However, D&S\jdoe will belong, after joining the new domain,
to an old account that's no longer around, which means that Windows
will put their profile somewhere else -- probably something like
D&S\jdoe.EXAMPLE. Odds are, though, that the old path will still be
in the registry or other files, which means a lot of cycles of
"Why-did-that-break-let-me-fix-it". Another option is simply to move
D&S\jdoe out of the way, so that paths can remain the same. Finally,
you can also change ownership recursively to the new account once
you've joined the domain; this will take a while, but it's probably
quicker than copying the profile over wholecloth if they've got a lot
of files. If you do this, it's best to remove the machine's copy of
their NTUSER.DAT file; it'll just be copied over from the server.
This took a lot of work, of course, and usually there were things like
Outlook.pst to screw things up further. But after much work, I
finally got everyone moved over to the new domain, and things were
good again.
Lessons learned:
Some days are fun days. I got this error on a Debian workstation when starting X:
Xlib: Connection to ":0.0" refused by server Xblib: Protocol not
supported by server. Xrdb: Can't open display ':0'
Turns out that an .xsession file, with one commented-out line,
caused that. Remove the line (so now it's empty) and everything works.
Next we got the same user, who's had his home directory moved around
on the machine. Machines mounting his home dir via amd (FreeBSD,
Debian) work fine, but the SuSE machines running autofs fail
miserably with "permission denied" and the ever-popular:
$ cd
-bash: cd: /home/foo: Unknown error 521
Which, if you look up /usr/include/linux/errno.h -- which, you know,
is the logical thing to do -- you see this:
/* Defined for the NFSv3 protocol */
#define EBADHANDLE 521 /* Illegal NFS file handle */
Another weird thing with AutoFS: I was running cfengine on a machine, and it hung when querying which RPMs were installed. strace on the rpm command shows its trying to lock a file and failing; looking at /proc/number/fd shows that, yep, it's trying and failing to lock /var/lib/rpm/Packages, the Berkeley DB file that knows all and sees all. So lsof to see who's holding it open, and that hangs; strace shows it's hanging trying to access the home directory of a user whose machine is down right now for reinstall. Try to unmount that directory and it fails. So I bring up the machine with the user's home directory, which allows me to unmount his home directory on the SuSE machine, which allows cfengine to run rpm, which succeeds in locking the Berkely DB file. Strange; possibly similar to this problem.
On top of everything else, someone asked me if I could be a "network prime". I think they mean "person we can talk to with authority to make network changes", or possibly "network contact". Not entirely sure.
But on the other hand: figured out how to run wpkg, package
manager for Windows of the elder gods, as a service using
Cygwin's cygrunsrv. The instructions are on the wiki for
your viewing enjoyment.
Version 0.3 of Windflower, the command-line-only, runnable-via-SSH Perl wrapper around the Microsoft Baseline Security Analyzer, is now ready for download. Improvements include:
It's not perfect -- it won't remove files after they're no longer needed, and the documentation needs to be better -- but it's pretty good.
Saturday after Patch Tuesday, and I spent far too much time today dealing with it. KB 911564 (aka Vulnerability in Windows Media Player Plug-in with Non-Microsoft Internet Browsers Could Allow Remote Code Execution) simply would not work, remotely nor interactively nor interactively through the Windows Update website. In the end, we had to go around booting machines into fucking safe mode (thank you, the posters of this thread, for the tip) in order to get the damned things to apply.
Sysinternal's handle showed that WinLogon.exe, for some reason, had C:\Program Files\Windows Media Player open, on one machine we checked that was having problems. No idea why, but it's about the only thing we could find that might be causing problems.
However, the news wasn't entirely bad...Windflower, the Perl-based rewrite of Ivy, actually patched a few machines today over an SSH session. Version 0.2 is available here. Hurray!
A user at work wanted to move from a desktop machine to a laptop. The
Windows profile moved over just fine, so all that was left to do was
copy over his outlook.pst. Only it turns out his desktop's hard
drive has been quietly failing for a while, and there's some
corruption right in his 1.2GB Outlook file. Well, fuck.
The Inbox Recover Tool is meant to help with this sort of
thing. It took me a while to find a mention of that, longer to realize
that it was actually called scanpst.exe, and even longer to decide
that the Windows search tool wasn't going to find C:\Program
Files\Common Files\MAPI\1033 -- a fact that is fucking buried in
Microsoft's Office support section. (Why 1033? Something to do with
Unicode and US English character sets.) Of course, it didn't work.
So okay, what about getting Outlook to export to another file? Good idea! Only it fails about 700MB through, and there's no indication what worked and what didn't -- so no chance for the user to decide if that's enough or not.
So what about exporting a subset of the folders, seeing what fails, and then repeating the process without the failing folder? A little tedious, sure, but it'll work, right? Wrong: you can export one folder, or you can export one folder and its subfolders, but you cannot export more than one folder at one time. Jesus fucking Christ!
Workaround for that was to copy folders (one at a fucking time, natch) to another folder (call it Backup) and try exporting that -- and then see what fails, yadda yadda. But natch, that doesn't work either. You have to watch closely to see what folders are being exported, and anyway a folder may be displayed as being exported more than once, so you still don't know whether a given folder may have worked.
Plus, there was the failing hard drive (remember that?); I suspect that it this new backup folder was just getting thrown on the same crappy chunk of hard drive, making the export of the Backup folder fail in interestingly inconsistent ways. And of course, the whole process takes fifteen minutes to fail, during which time I can't do anything else and neither can the user.
And in the middle of my frustration and rage, an even greater rage welled up in me when I realized that Outlook had totally ruined this guy's email.
Think about it! Here's all this plain text email -- even attachments are encoded in ASCII -- and it has been completely fucking borked by being irretrievably (well, in this case anyway) converted to some proprietary binary format that is completely opaque to me, without at least the saving grace of having good tools for its manipulation available. Redundancy, ease of recovery and ease of manipulation has been thrown away for the sake of (let's be generous here) speed and functionality (indexing, correlation, etc). It's completely ridiculous.
This led to the formation of Saint Aardvark's Axiom of Information Utility:
Any sufficiently important information must be indistinguishable from plain text.
Plain text is redundant, easily (though not necessarily speedily) recognized by the human brain, and has many automated tools to deal with it (think of Unix). All these things make it very, very recoverable. If the information is that important, you need to be able to get at it even if there's a hardware failure. Binary formats throw that away, and that is simply wrong.
But what's a self-important axiom without an equally self-important corrollary?
Any gains in the functionality or speed of information access must be obtained from derived versions of the original information, leaving the original in its plain text form.
I'm perfectly willing to give Outlook the benefit of the doubt in this case; having used a PDA for all of two weeks, I feel uniquely qualified to recognize the utility of having cross-referenced contacts, to-do lists, email, and so on. But this must not come at the expense of recovery!
Think of source code. It's possible to hack on a binary with a hex
editor or a disassembler. You can even fix bugs or change the way a
program works in this way. But you would never maintain a program in
this way: it's hard to understand, it's easy to make a mistake, and
it's hard to (say) port to a new language or hardware platform. That's
what source code is for: it's easy to understand (assuming you're a
programmer), and even if some of it gets garbled it's easy to
recover. Plus, you can use tools like indent to change how it looks,
or grep to pick out interesting bits, or tags to cross-reference
function calls with their definitions.
Of course, you wouldn't try to run source code -- that's what a compiler is for. You gain speed by transforming the source code while still leaving that source code intact: nothing is lost in the process. And that's what Outlook should have done: compiled the plain text email into whatever database (I'm assuming) format Outlook likes, that allows Outlook to do Outlook stuff quickly, while still leaving the original source code -- the email -- intact.
Of course, you don't have to imagine recompiling Outlook's PST file each time; this'd be an incremental thing. And really, it shouldn't be that much different from what it does now...same speed, just a little more disk space taken up. And if the PST file gets borked, no matter -- the recovery tool is nothing more than a compiler that regenerates it from the original email.
As much as I'm picking on Outlook though, this isn't Outlook's problem alone. I've written before about how PHPWiki obscures the information it stores in MySQL. And I did a similar thing to myself years ago by compressing email, since I was running out of disk space. Somewhere along the way the files got corrupted, and I can't get that email back because gzip barfs on it.
And of course, this is just my opinion, formed in the heat of anger. It's almost certainly not a new idea, and might even be wrong. I'd love to hear some feedback on this.
Been a lot happening here that I haven't written down...time to correct that.
First off, work is BUSY. We have ten -- no, wait, twelve -- -- people starting this month. About 8 have started already, so that leaves four. Fortunately, one of them is a new sysadmin who will be helping me out. Thank whoever for small mercies.
The sheer number of people has been part of the reason I've been so busy; another has been the Windows patches this month. Three goddamn times I've been in this month patching machines: once with the unofficial WMF fix, once with the out-of-band official WMF fix, and once with the two regular patch Tuesday patches. I am sick and tired of Windows problems.
However, I have managed to cobble together Windflower, a small-and-so-far-stupid Perl wrapper around the Microsoft Security Baseline Analyzer. So far it will run MSBA on the target computer and come up with a list of fixes it would like to see applied. It'll run over SSH, which is a blessing; I envision this as a way of automagically applying Windows patches remotely without getting a copy of SUS and IIS. It's called Windflower because it's heavily influenced/inspired by Daisy and Ivy, two programs released by Virginia Tech. (It was originally gonna be called Sunflower, but it turns out VT has already released a program with that name...I had no idea 'til now.)
Why not stick with Ivy (which worked better for me than Daisy)? Ivy's great, but it needs a GUI and its UI is irritating (keeps stealing focus, new logs overwrite old logs, etc). I've long wanted something that can work over SSH, and this looks like it should be able to. Plus, Ivy was written in Winbatch, which I don't know and don't have a compiler for. Windflower is written in Perl, which I do know pretty well.
Version 0.1, in all its completely unfinished glory, is available here. GPL'd for open-source goodness!
There's also Amanda, which has been giving me grief. First the
estimates were taking hours to finish, which meant that even if
backups started at 9pm they wouldn't finish 'til noon the next
day. This was fixed by upgrading to 2.4.5, which uses calcsize,
quicker-but-slightly-more-inaccurate estimator of the Elder Gods.
Then I ran into another problem: estimate requests, including all the exclusions for each directory, were taking up more than 32KB -- so they were split up into more than one packet by the requesting process. Unfortunately, the receiving process still ignores all but the first packet. Patches, as they say, are welcomed; in the meantime, the workaround is to make the packets smaller. The easiest way to do that is to have one big list of exclusions, rather than specifying each item in that list for each backup. The problem with that is that leads to problems where you (say) want to exclude certain stuff for everyone, plus allow people to specify their own list of exclusions: only the first list gets accepted. My own special workaround, hereby released under the GPL, is:
for i in `ypcat passwd.byuid | awk -F":" '{print $1}'` ; do
cat /path/to/onebiglist >> $i/.exclude_from_backup
done
Arghhh.
One thing that has helped with work is Time Management for System Administrators, by Tom Limoncelli. I just got this last week, but it's already helped a lot. The sample chapter gives a good overview of The Cycle, the system that TL advocates. The book irritates me in a couple places -- the odd buzzword, and an illustrative anecdote about a friend who was late reviewing a chapter that, frankly, makes TL sound like a bit of an ass. But these are pretty minor complaints, and I recommend getting it.
One of the things he recommends is either a PDA or a PAA (personal analog assistant, aka DayTimer(tm)). I decided to hunt around Ebay for a PDA, thinking I would pick up a used Handspring or some such; instead, I got a Sharp Zaurus SL-5500. Woohoo! Should be arriving next Wednesday.
Finally, I managed to spend a couple hours last night hacking on the
NWR04B. I got the driver for the ADM5120 switch compiled;
however, it hung when it came time to initialize the switch. A liberal
sprinkling of printks showed that the kernel was hung in
register_netdev at the call to rtnl_lock. Just for fun, I tried
taking that out, and the initialization continued...though other
networking drivers complained about RTNL_ASSERT failing, and the
ethernet interface didn't actually work, since it couldn't mount its
home directory via NFS. Still, progress of a sort.
In here attempting to patch the 35 or so Windows machines that we've got at work. So far, it looks like I should be able to do this remotely using SSH and Cygwin. That depends, of course, on having very fucking silent ways of running everything. So far this has worked for me, on XP/SP2 and 2K/SP4:
regsvr32: None of the bits I've seen from SANS mentions it, but
there is a silent option. Do it like so: regsvr32 /s /u
%windir%\wystem32\shimgvw.dll However: I cannot get %windir% to
work with Cygwin. According to this it should work as
%WINDIR%, but it doesn't for me. Two things do seem to work: either
change directory to /cygdrive/c (Cygwin-specific location of the C:
drive) and use an absolute path (winnt\\system32\\shimgvw.dll), or
run CMD to get a DOS/Windows shell and use %windir%.
The Unofficial Patch: Use the options: /VERYSILENT
/SUPPRESSMSGBOXES However, it has problems if you try applying it on
a machine that already has had the patch -- remotely, execution will
just hang. If you run it locally w/o those options, you'll get a
message saying it's already been applied; I guess that case is not
handled well when run silently. Oh, and when the patch is applied
silently, it'll reboot the machine immediately and without warning.
Thanks to Cygwin, I've got SSH running on most Windows machines here; I should be able to come up with some way of doing this all in one step. I'll post whatever I can figure out.
Update: Yep, a simple batch file does the trick:
regsvr32 /s /u %windir%\system32\shimgvw.dll c:\cygwin\home\Administrator\wmffix_hexblog13.exe /VERYSILENT /SUPPRESSMSGBOXES
chmod 755 both the batch file and the fix, and away we go. The machine passes the test made by the guy who wrote the unofficial patch, which is as close as I think I can come to being sure that it all works. Further Update: Four hours later, done...but I've finally got SSH set up on the few machines I had left, so that's what took up most of the time.
Okay, number one: I love Sysinternals. Not enough that the guy takes on Sony...no, he's gotta make Windows utilities that MS should've made and releases 'em gratis. Not only that, they're text-friendly: Regmon saves log files in fucking text, the way God intended. Sweet.
Number two: Weird-ass problem with Office 2003 on this one computer. Check out the result of a simple browse through the user's home directory on a Samba server:
104 HKCR\CLSID\{0AFACED1-E828-11D1-9187-B532F1E9575D}\ShellFolder\CallForAttributes
104 HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\NonEnum\{0AFACED1-E828-11D1-9187-B532F1E9575D}
158 HKCR\CLSID\{0AFACED1-E828-11D1-9187-B532F1E9575D}\InProcServer32\(Default)
158 HKCR\CLSID\{0AFACED1-E828-11D1-9187-B532F1E9575D}\InProcServer32\LoadWithoutCOM
433 HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User
463 HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints\D\Version
3952 HKLM\Software\Policies\Microsoft\System\DNSclient\PrimaryDnsSuffix
3952 HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Domain
3952 HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Hostname
3956 HKLM\System\CurrentControlSet\Control\ComputerName\ActiveComputerName\ComputerName
Four thousand checksk of PrimaryDnsSuffix, Domain, Hostname and ComputerName. WTF is going on?
For the second time in two weeks, an executable (!) Windows virus inside a .zip file has made it past ClamAV because signatures had not yet made it to the database. (What I mean is, the file extension alone was enough to show it was an executable.) The first time it happened, I came up with a very quick and dirty patch for ClamAV; now I'm applying it.
I think it should work...all it does is use ClamAV's own code for detecting a Windows executable and return a bit early when scanning a file. I wanted to use ClamAV rather than MIMEDefang because Clam has code built-in for safely scanning ZIP files, and I wanted to avoid having to code something like that on my own in MDF. But if someone out there knows a good way of doing this, please let me know; Google didn't turn up anything I was happy with.
I've not yet submitted this to the ClamAV mailing list, but I'm sure that there are many good reasons it should be laughed out of town. If this is useful to you, great, but I promise nothing. I do NOT recommend applying it. It will probably break everything, refuse to run, and end up hiding WMD in your bedroom. It's your responsibility to make sure it works for you. But hey, if you like playing with patches to important software by people who don't know what they're doing, enjoy! (Just to be explicit: released under the GPL.)
(BTW, the patch is suitable for dropping into FreeBSD's ports at /usr/ports/security/clamav/files. At least, it works for me...)
UPDATE: The patch now covers clamd, not just clamscan, and also updates the man pages. Whee!
Problem: Outlook 2003 User gets a message from System Administrator saying that his message to a coworker is undeliverable -- something about relaying denied -- and asks me why this happens.
Pretty simple, right? Just get him to forward the message and then check the logs. Only no, it's not simple: despite twiddling all the bits you're supposed to, I keep getting the message attachments in MS' TNEF format. I use Mutt. I give up and decide to look at Outlook itself. (Yes, I know about the decoder scripts you can get, but I was being bullheaded.)
Now we have the problem of getting the proper Internet headers in the email. (I've given up trying to persuade Outlook that I am ritually pure enough to look upon the shining glory that is The Message Source without melting like some kind of Nazi-collaborating French archaeologist; it doesn't work.)
A quick Google turns up three suggestions: a $24.95 VB plugin, giving up entirely, or right-clicking and selecting Options, then looking at the box that sez Internet Headers. I'm game, so I try right-clicking and choosing Options. There's the Internet Headers box, all right, but it's empty. WTF? I look around, but there's nowhere else to clickyclick.
I try right-clicking on another message, and sure enough it shows the headers. I try selecting the From address in the problem message (helpfully labelled as "System Administrator", which I'm pretty sure is a bald-faced lie), then Properties. It just says it's from System Administrator, and shows no actual, real email address. You remember...email, one of the things Outlook is meant to do?
Then it dawns on me: the mentioned-in-passing comment from the user that the message is probably from Outlook itself is true. I'd thought this was just a friendly gloss on an unfriendly message, but it wasn't. This fucking message is from Outlook. And it's not until I skip ahead and tell you the exciting conclusion -- it was our mail server refusing to relay and saying so, something never not once mentioned in the offending message -- that you're going to realize the full horror of the situation.
For Outlook does not only mangle email, and hide attachments in weird files called "winmail.dat", and shake its baloney all over the place like a drugged-out Hula girl in the "Before" picture in all those rehab clinic advertisements. No. That is not all.
Outlook -- the mail client -- also takes error messages from mail servers and disguises them as email messages that have just arrived, rather than showing the user the fucking error as an error when and as it occurs! It hides the origin of the error by pretending to be some non-existant sysadmin when it sends this message! And it does nothing to indicate that this false email is any different from the other messages from Bill and Bob and Ted littering your inbox about horizontal opportunity mission statements, complete with an animated surfing guy for Bob shouting "Whoah!" to differentiate his mangling of the English language from Ted's, leaving me to wonder what the fuck kind of congenital brain damage must've been at work to make this seem like a good idea to anyone.
Fuck me, I hate Outlook.
If your W2K Pro computer hangs during boot with the message "Applying
security policy..." but eventually (5-25 minutes later) boots, you may
want to look at this link...worked for me today. One little bit
of clarification: I found no .chk file in the Security folder. This
doesn't appear to have hurt anything.
Somebody PLEASE explain to me why the W2K shell does not include a
Windows equivalent of chmod by default, and why its closes equivalent,
cacls, only comes with the $x00 resource kit. Here's what happened:
Thank God for Cygwin.
Holy crap, I'm busy these days. First off, it's MS patch week. That
means I'm in here on a Saturday afternoon patching by hand. Yes,
you're right, it's very ugly; this is why I'm trying out a couple of
things that I hope will make it easier. The first is Daisy, a
program (and by the way, the next time someone says "solution" when
they mean "program" ah munna punchem inna cock) from the
University of Virginia Virginia Tech (thanks, Joe)
that
It has a couple problems that seem mostly due to the program they use to scan for missing patches -- always seems to say that the same three patches are needed, whether or not they've been applied -- but overall I'm quite happy with it.
The next thing I'm trying is running Daisy
remotely, by installing Cygwin and SSH on each of the
machines. Unfortunately, this isn't working so well; the same
command-line options that work from a local shell (whether Cygwin or
cmd) just don't when I'm logged in by SSH: it says that it can't see
that any patches have been applied, tries to download 'em all from
the local repository I've set up, and is very unhappy when they're not
there.
Next thought is to try installing crontab and shutdown with Cygwin and use crontab to run Daisy (or other patches) locally. That has problems too: Cygwin looooooves updating everything, and if you've (say) installed Cygwin a year ago and haven't bothered updating it since, it runs around trying to download newer versions of everything. What's more, there's no way to turn off that behaviour in the installer...very annoying. I think I'll try installing crontab and shutdown individually (managed to find a script a while back to do that properly), and see how it goes. Of course, since I've just applied all the patches for this month, it's gonna have to wait.
Which is fine, because second, I found out on Thursday that a dozen people are moving to a temporary office for two months, they'll be there May 2nd, and I have to make sure they can still work while they do that. A bunch of them are doing nightly regression tests; this means their files will need to be here, but a 1Mb/s cable link and X forwarding is gonna be mighty painful. (Or so I'm told...why they can't just use SSH and vi for everything is beyond me...grumble...)
I called around to see if anyone could set up a temporary LAN extension over fiber or some such, for two months, with two weeks' notice. HA! Not a chance: a six-month contract and a six-week lead time was the best anyone was willing to offer. But hey, not a problem -- the new place is maybe 150 metres away as the crow flies, and we've got line of sight in between here and there -- hell, I can see the corner office from here.
So I called up Telus and asked them if they could do this. "Sure can!" said the bright young man I was dealing with, and you could hear the wind from his enthusiastic nodding. "We'll do 802.11g between here and there. It's perfect! And it only takes 8 weeks to do a site survey!" I reminded him of my two week deadline. "Not a problem! We'll just convert it after the move to wireless Internet access over your entire office! The boardroom, the desktop, the kitchen...and we remotely monitor it to prevent intrusion! We'll use whatever authentication standard you're using! We try to stay away from WAP, but we can use WEP if you like!" Sigh...okay, how much? "Forty-five thousand dollars. How soon do you think you'll be able to take advantage of this opportunity?"
Fortunately, I found another ISP that's interested in mounting an antenna on the roof just to be able to offer their service to other tenants. Looking good so far. And since they offer gigabit Internet access for $500/month, I'm thinking the price can't be that bad. (Yeah, gigabit 'til the first router that isn't theirs. But still.)
Third, I'm still trying to get the Promise VTrak up and running here. Still running out of space, still haven't had much time to play around with it. Well, except for today. Starting to find a couple things that are annoying (besides the GPL violations, I mean). First off, it looks like changing the cache policy on a logical drive (ie, from write-through to write-back) requires a reboot of the array itself (!) to take effect. Second, even without changing the write-back policy, it looks like a reboot of the array makes a newly-created logical drive orders of magnitude faster -- ie, bringing it up to an acceptable speed. (I'm not certain of that, though, so grain of salt etc.) Third, no MIBs/OIDs -- whatever the proper term is -- for SNMP are shipped with the documentation...still trying to get this out of Promise.
From procinfo(8), part of sysutils:
-Ffile Redirect output to file (usually a tty).
Nice if, for example, you want to run procinfo permanently on a
virtual console or on a terminal, by starting it from init(8) with
a line like: p8:23:respawn:/usr/bin/procinfo -biDn1 -F/dev/tty8 `
At last, a Linux equivalent of systat -vm. Or nearly,
anyway.
A real OS shows messages when it's booting to let you know how far along it's gone. If something goes wrong, you can see where. A real OS doesn't have a fucking marquee of slowly-changing colour that you have to stare at intently from six inches away to see if it's frozen in place and yet another cold reboot needs to happen. Oh, and it logs how the boot went. Every time. Without being asked.
Also, if an OS comes with a package manager -- and a real OS does -- it shows you the fucking version of the software that's installed. A real OS knows that knowing ~FooTastic installed is only half the battle -- knowing that it's the buggy 6.2 build is just as important.
I try to give Windows and Microsoft a chance, I really do. But this is fucking ridiculous.
My prayers are answered. Submitted this as a story, but got rejected; in case it doesn't show up, have a look: SpamAssassin for Windows, Perl Artistic License, easy to set up. Just trying it out now. Slow so far, but it's in beta.