# svcadm enable iscsitgt

As my Solaris install is still quite fresh I got a spare disk in it. It should carry my iscsi pool which I will just call ‘iscsistore’. Keeping it on a separate disk allows me to export it independently. So here we go:

# zpool create iscsistore c0t1d0

If you think that I have to mess around with dd now to write containers, you’re wrong. ZFS does this for us elegantly:

# zfs create -s -V 10gb iscsistore/zvol

Now the iSCSI shares:

# zfs set shareiscsi=on iscsistore/zvol

We check:

# iscsitadm list target -v

And that’s it. We’re ready to roll. Simple and easy. Simply ZFS.

As it was possible to take the assurer test on site – god bless the inventor of wireless lan – I could start to assure people immediately and gain the first ‘Administrative Points’ which enables me to distribute 15 points at once by now.

Update: At the end of the day I could already grant 25 points.

The procedure itself isn’t something new – the only difference is that you don’t sign the certificate yourself. We start (as usual) with a certificate request:

openssl req -nodes -new -keyout server.key -out server.csr

This request – filed so server.csr is now passed on to CACert, who now generates and signs the certificate for us. Using it on our server isn’t a big deal as long as our clients got the root certificate to validate it. If they don’t, it is very easy to get it:

wget -nv https://www.cacert.org/certs/root.crt -O /etc/ssl/certs/CAcert.org_Root_Certificate.pem

The rest is pretty straight forward. Here is an example for doing it with postfix:

# TLS PART START
smtp_tls_CAfile = /etc/postfix/tls/root.crt
smtp_tls_cert_file = /etc/postfix/tls/server.pem
smtp_tls_key_file = /etc/postfix/tls/key.pem
smtp_tls_session_cache_database = btree:$data_directory/smtp_tls_session_cache
smtp_use_tls = yes

smtpd_tls_CAfile = /etc/postfix/tls/root.crt
smtpd_tls_cert_file = /etc/postfix/tls/server.pem
smtpd_tls_key_file = /etc/postfix/tls/key.pem
smtpd_tls_session_cache_database = btree:$data_directory/smtpd_tls_session_cache
smtpd_use_tls = yes

smtpd_tls_received_header = yes
smtpd_tls_ask_ccert = yes
smtpd_tls_loglevel = 1

tls_random_source = dev:/dev/urandom
# TLS PART END

After doing a reload, we can proceed to the test which has been passed by my system already. As anything is set up and shouldn’t need to be changed until a new certificate comes in, I’m done and so I sit there saying ‘safe paths’ to my files passing by.

Regarding long term statistics, you might be stumbled across the RRD Tool or MRTG. But as configuration is quite complicated, a nice front end named Cacti even does auto detection…

As I did some hardware maintenance I was forced to do my internal server from scratch which was a good start to search for good monitoring solutions. So I started looking around and came across Groundwork Monitor and some other Nagios Front-Ends until I finally found Zenoss which looked like a suitable alternative – but the installation failed due to their outdated build tools they’d require.

As I was not really successful in fixing those numerous bugs in the installation routine I went on and found Zabbix – a tool that claims to be the perfect solution if you can trust their homepage. There was even an outdated ebuild in portage which needed some love. I did an updated version and put it in my overlay – so the installation wasn’t a problem and I could start with the configuration, which happened via Web interface which looked quite complicated at the first glance. But once you got the logic, it is straight forward and simple.

For monitoring remote machines, Zabbix offers Agents which are even available for Windows and Apple. But nevertheless you can use SNMP and Shell scripts to get things done. So if you’d ask me, Zabbix is a really powerful solution. It even uses less resources than my previous nagios / cacti solution.

For keeping it simple, I usually use ‘Full access’ for network shares for everybody, restricting anything on the file system layer which usually does the trick. My permission set is regarding the file might be restrictive, but it is fine. Copying the file to a local drive proofs, that the file isn’t damaged.

As I run out for ideas I was doing something else until an idea suddenly became manifested. The Internet Explorer, a core system component of windows is even used for browsing files. Its restrictions might be the cause for my troubles. Proofing this shouldn’t be hard at all.

After updating to the newest version (which should be IE8 at point of writing) I just did a ‘factory reset’ of all the permissions resetting them to their defaults, which suddenly granted me the permission to execute files from the LAN.

As I’m used to Linux systems, my first click was firing up the Console windows for accessing the bash shell. As the problem is smb related, it’s something the kernel might know something about. For accessing the kernel log, I used ‘dmesg’, which showed us the following error message:

smb_smb_negotiate: server configuration requires packet signing, which we dont support
mount_smbfs: error from NetrShareEnum call: exception = 382312522
smbfs_smb_qfsattr: (fyi) share 'NTFS', attr 0x700ff, maxfilename 255
smbfs_aclsflunksniff: group sid S-1-5-21-2788770225-3767355608-264476496-513 didnt map


The problem so far: Windows does packet signing for preventing a security breach with its network shares. Searching for a solution, I have stumbled about the newest OSX version which would be one option to handle the problem as disabling packet signing would degrade network security at the whole network. From my point of view, apple security looks more and more like a myth to me.

Update – 2009-04-29: It is not a big surprise for me, but the new line to be is still dead and it looks like the telekom service didn’t finish it correctly. So the move is still pending. Worst case scenario would be being offline for a week or two…

Update – 2009-04-30: If it’s not the provider or the telekom causing troubles, it’s the charlady causing troubles by unplugging the server rack for using the power plug. Systems are up again, but still at the old location. Sorry for the inconvenience.

Update – 2009-05-04: Today our Telekom announced that a technical guy will come round looking at the problem to (hopefully) solve it. Just to be sure, I got me an SDSL Modem to be able to check their work afterwards without taking my servers down…

Update – 2009-05-07: Just before we all gave up, a miracle happened: the modem started connecting and my ISP could finally start configuring it for the final testing. To be honest, we’re suspecting the telekom guy has forgotten to remove the testing plug at the other end of the line – but who knows.

Update – 2009-05-12: After some line tests and preparations the server move happened today. All systems are now up and running in their new home.

As already told in the post dealing with the new server, it was no big deal doing the setup as it’s good hardware. No quirks, no hacking – just straight forward.

Honestly, I do. This article here should be a small report of my attempt to get an old IBM Server for my rack. To keep the price low, I usually don’t place a bid if the auction time left is greater than 1 minute, hoping to get the server for a reasonable price.

Last week I watched 30 Server. 25 of them even had a reasonable price and I could place my bid. Regarding those 25 bids, I was successful in 22 cases. But I wasn’t lucky at all: I have lost every box during the last 3 to 5 seconds. Missed it for 50 Cent to 1 EUR.

In other words I didn’t get a single box.

Regarding SSL Certificates, there are two possibilities: you may buy an official one or you may generate your own. Due to financial reasons, I’m using the latter method, as it’s more or less for private use and not for granting my servers ID. But that’s enough chit chat – let’s go to work:

Step 1: The Private Key

We start by creating our RSA Private Key, which should be a 1024 bit RSA key. Encryption could be Triple-DES. As the key has to be stored in ASCII text, we’re using the PEM format.

openssl genrsa -des3 -out server.key 1024

Generating RSA private key, 1024 bit long modulus
.........................................................++++++
........++++++
e is 65537 (0x10001)
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:

Step 2: The CSR (Certificate Signing Request)

A CSR, as the name already says is the request for the certificate, just like an application form used at any bureaucratic process for collecting information from you. Normally you’d send it to Verisign or Thawte if you want to have an official certificate for your server. But in our case, we’re processing it ourselves.

While filling in the requested data, you will stumble upon a question like that: “Common Name (e.g., YOUR name)”. It is important that you enter the fully qualified domain name of the server to be protected here. If I would run my blog through SSL, it would be ‘my.stargazer.at’.


openssl req -new -key server.key -out server.csr

Country Name (2 letter code) [AT]:AT
State or Province Name (full name) [Feldkirch]:Feldkirch
Locality Name (eg, city) [Nofels]:Nofels
Organization Name (eg, company) [My Company Ltd]:STARGAZER systems
Organizational Unit Name (eg, section) []:IT Core services
Common Name (eg, your name or your server's hostname) []:my.stargazer.at
Email Address []: *****@******.***
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:


Step 3: Removing the password

I know, this might sound strange to you, but this step ensures, that your server is able to start up without user interaction. To understand that, you need to know, that the server key is encrypted by now, which makes it unreadable until you enter a correct passphrase. As we are starting our webserver via init script, we would be prompted for unlocking the key, which denies unattended startups. (We’re decrypting it)


cp server.key server.key.org
openssl rsa -in server.key.org -out server.key


Step 4: Generating the Certificate

Now we’re generating the certificate. Regarding validity, we are using one year. After that time, we’ll be doing the same procedure again ;)

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Signature ok
subject=/C=AT/ST=Feldkirch/L=Nofels/O=STARGAZER systems/OU=IT Core services/CN=my.stargazer.at/Email=*****@******.***
Getting Private key

Step 5: Making use of the Certificate

By now our important files server.crt and server.key are ready for use. So let’s clean up the mess we have made before and copy the new files to a safe place. Yes, I am talking about backups. The configuration of the webserver itself shouldn’t be that hard. For my apache webserver, I’m extending my configuration that way:

SSLEngine on
SSLCertificateFile /etc/apache2/ssl/ssl.crt/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/ssl.key/server.key
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

Step 6: Restarting Apache

Finally we have to restart our webserver to apply the changes and we are ready for our first test run.