I just read an article which scared the hell out of me! There is an EU proposal to require a government controlled registry of blogs. No more anonymous blogging!

"there is a need to clarify their status, and to create legal safeguards for use in the event of lawsuits as well as to establish a right to reply" in other words each blog needs to have an publisher, just like a newspaper, and this will require you to register with the local authorities. No more whistle blowing through blogs...

I wonder how they plan to enforce this? Especially in a case like mine where the server resides outside the EU.

I just read a good blog entry about the decay of the Swedish model which touched on many subjects discussed during dinner today.

People here (in Sweden) seem to think the someone else will take care of it. It is not my problem, but someone ought to do something about it. Why isn't the government doing anything about it?

Why not do it yourself?

I've come a fair bit in my puppet testing now, but one thing I lack is a user_attr type. I.e. a way to update the /etc/user_attr file using puppet.

This is what I have in mind for the syntax:

user_attr { "martin":
    type => normal,
    roles => [
        "root",
        "admin"
    ],
    profiles => "Zone Management",
    auths => [
        "solaris.mail.mailq",
        "solaris.system.shutdown"
    ]
}

One thing I haven't figured out yet is how if the definitions should be absolute, i.e. if the entry must be exactly like the definition, or if it is enough that the listed values are present. In the above example, should the role list be exactly root,admin or should it just make sure that those two roles are in the list and you can have the role audit too. Perhaps it would be good to be able to use the absent/present syntax on individual items?

I haven't decided if I'm going to manage the other user attributes too, e.g. project, defaultpriv, limitpriv and lock_after_retries. I will probably leave that for a later release...

[Technorati Tags: OpenSolaris Solaris Security Puppet ]

I've set up a puppet environment which uses mercurial to store the configuration and manifests. Now I'm trying to build an environment to be able to test changes before I commit them to the repository, and they propagate to all our 400 servers - but I encountered a problem.

You can use a separate configuration directory with the --confdir option for both puppetd and puppetmasterd, and run everything on localhost, but the problem is the source parameter

file { "/etc/profile":
    owner => root,
    group => root,
    mode => 644,
    source => "puppet://server/base/profile"
}

The above source parameter contains the hostname, so when I want to test it on my local mercurial repository, it still connects to the server instead of localhost when it fetches the files.

Luckily there is a solution! If you leave out the server part, puppetd will insert the name of the server it is connecting to.

I'm looking for ways to better manage our servers, and right now I'm playing with puppet.

I immediately ran in to a problem: it picked the wrong domain name. Internally at Sun we use NIS (yes, I know it is insecure and sucks in almost all aspects, but I'm not in position to change it - and believe me I have tried) and our NIS domain name doesn't match the DNS domain name.

This is something puppet (facter to be exact) doesn't figure out, at least not on Solaris. Instead of picking the correct fqdn for a host, e.g. puppetd.sfbay.sun.com, it picks puppetd.mpklab.sfbay.sun.com, since that is what the domainname command returns.

They tried to fix this, but unfortunately it doesn't work for Solaris, as it relies on the dnsdomainname which we don't have.

I've worked around it by creating my own /usr/bin/dnsdomainname which gets called before domainname.

#!/bin/sh
DOMAIN="`/usr/bin/domainname 2> /dev/null`"
if [ ! -z "$DOMAIN" ]; then
    echo $DOMAIN | sed 's/^[^.]*.//'
fi

So now I can continue to test my puppet configurations...

I'm headed to California and Menlo Park on Friday, and my wife has as usual given me a shopping list :)

With the dollar as lows as it is, I'm going to do some shopping myself. I'm going to buy a Time Capsule, not that I really need an extra 1 TB disk, but the rest of my family (whom I've converted to Mac) never remember to turn on the external disk I've attached to their computer - so Time Machine is useless!

And for myself, I'm going to get two 1 TB disks for my Drobo, which is 97% full at the moment. I'm squirreling away too much, but it is hard to throw away stuff... I've even got things stashed away on other external disks, but that data isn't mirrored which I don't like.

Since I got a digital video camera, I never seem to have enough disk space. I can't wait until our house is built and I can set up my U40 as a file server - 8 * 1 TB should last at least until the end of 2008 ;)

I've checked up on how my friends are progressing with the AuditAnalyzer and they have gotten quite far!

I've played with some pre-alpha stuff off and on, and the main problem have been importing audit data into the database - it has been too slow. It has managed to import about 150 records/second, which may sound much but if you are like me and get audit trails from 300+ systems, it is not enough to keep up with the stream of inbound records.

Luckily they worked on the import speed now, and have two possible solutions. One yields around 1500 records/second and the other a whopping 4500 records/second!

I can't wait until they have a new version available for me to try out :)

[Technorati Tags: Solaris ] Security ]

Out esteemed director has pushed us too far too long - he requires us to rack 'em and stack 'em all day long, and after the last spree of installing alpha hardware he got from engineering (the new 4 way, 16-core Rock based systems, code name lurad) for the www.sun.com cluster we now have such a big mess in our server room that I thought I'd share it with you:

Picture by: VespaGT

We have added 72 of these little monsters since the beginning of last week and haven't had time to clean up the cables - so now it is time to bring out the dymo and start labeling...

[Technorati Tags: Sun Solaris ]

I'm going to war!

Unfortunately I can't blog about why, when and how yet, as I'm taking legal actions, but as soon as that is resolved I'll post it here.

Meanwhile, I'm looking for good info on consumer terrorism, like this book, and other ways to get back at the <beeeeeeeep> company that caused me considerable monetary damage and have wasted months of my time.

I've already registered a domain name where I'm going to push all information and documentation about this case, and I am thinking about typosquatting the company's site :)

Like my old boss said when I told him about it: Never pick on a pedantic security puke!

I've managed to solve the problem I was blogging about earlier.

I started out by forcing TimeMachine to do a backup and since I wasn't sure I'd succeed in restoring my data using it, I did a gtar backup of all user directories too.

Once the backups were done I booted the Leopard install DVD, started DiskUtility, and reformatted the disk as HFS, Journalling and Case Insensitive. After that I started TimeMachine and choose the restore option. It immediately reformatted my disk to match the backup, and that wasn't what I wanted.

So I reformatted the disk again and then choose to do an install from scratch. When the installation completed and the system rebooted, the migration assistant asked if I would like to mograte old data, and I picked the option to restore from the last TimeMachine backup.

This time is didn't do anything with my file system and all files & settings were restored - and I could start the Photoshop CS3 installation and get it installed!

I don't know how it would have handled a conflict, i.e. restoring foo and Foo, since I wrote a Perl script to make sure that I didn't have any conflicts.

cASe inSEnsITIvE file system - what an utterly stupid idea!

When I installed Leopard on my MacBook Pro it was a natural choice to make the file system case sensitive. Besides being a UNIX geek I had a legitimate reason for doing so:
you can't do

hg clone ssh://martin@hg.opensolaris.org/hg/audit/patches

as the OpenSolaris source code contains case insensitivity conflicts.

So what am I bitching about then? Yesterday I tried to install Adobe Photoshop CS3 on my wife's MacBook pro (which I also installed with case sensitivity) and got this very unintuitive dialog:

This software cannot be installed because the file system of the OS volume is not supported

After scratching my head for a while, I figured out that it is due to the case sensitivity! Adobe hasn't bothered to fix their code, and it is not like it is a new feature in Mac OS X either... they have had several years to fix it.

Unfortunately there is no solution to this, but to reformat the file system and make it case insensitive! To go from bad to worse I can't use TimeMachine to do it, as it too doesn't support backing up a case sensitive file system and restoring it to a case insensitive. It just has to alert me if there is a conflict - which there isn't in my case, I've checked!

Luckily Mac OS X comes with all the UNIX tools we love and cherish, so I'll just use cpio or gtar to back up all my data and then nuke the / partition (while keeping my zpool)

Update: as suggested by zdz and Dick Davies I tried creating a disk image with a case insensitive HFS, but that didn't work either for the Photoshop installer. The hint is in the error message "OS volume is not supported". Back to the original plan of backup/reinstall/restore...

Johann Lipowitz (David Armand) is back with two new hilarious mime acts:

I've been playing around with project Indiana, and the new installer and packaging system, and they are really nice.

When you install it turns the root disk into a zpool called zpl_slim, but it doesn't let you select two disks and mirror the zpool. Luckily you can fix this once the installation is done. When the system has booted, you can use the zpool attach command:

# zpool attach zpl_slim c7d0s0 c8d0s0
# zpool status
  pool: zpl_slim
 state: ONLINE
 scrub: resilver in progress, 11.75% done, 0h3m to go
config:

        NAME        STATE     READ WRITE CKSUM
        zpl_slim    ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            c7d0s0  ONLINE       0     0     0
            c8d0s0  ONLINE       0     0     0

errors: No known data errors

If you have turned root into a role in a zone and try to use zlogin from the global zone to log in as root you will see something like this:

root@global# zlogin zn1
[Connected to zone 'zn1' pts/2]
Login incorrect

[Connection to zone 'zn1' pts/2 closed]

This is because pam.conf is by default configured to prevent this, as roles must only be assumed by authorized users.

If you trust the ones who can become root in the global zone, you can change this restriction by adding the following line to pam.conf

zlogin  account required        pam_unix_account.so.1

Now you can zlogin directly to a role without having to first log in to a normal user:

root@global# zlogin zn1
[Connected to zone 'zn1' pts/2]
Sun Microsystems Inc.   SunOS 5.11      snv_75  October 2007
root@zn1#

Now that CSWpython is upgraded I've finally got my act together and found some spare cycles lying around in a drawer, so I could finish the update of the CSWmercurial package. I've sent it out for alfa-testing, so hopefully I'll be able to publish it by the end of next week.