make laten vliegen op je multicore systeem

Stel je hebt net je LPI 201 cursus gevolgd bij AT computing en je wilt even lekker oefenen met het configureren en compileren van de laatste kernel van kernel.org. Je hebt de kernel gedownload en uitgepakt en je denkt: ''weet je wat, als eerste eens even alles aanzetten om te zien wat er allemaal gemaakt wordt'':

make allyesconfig

En vervolgens bouwen maar:

make

Vol verwachting zie je de CC regels voorbij komen. Na 10 minuten begint dit toch wel erg te vervelen en vraag je je af waarom je dual quadcore systeem hier zo lang over doet. Je controleert even of alle cores wel door je systeem worden gedetecteerd:

cat /proc/cpuinfo

Ja hoor, ze staan er allemaal. Dan maar eens kijken met top wat het systeem allemaal aan het doen is (vergeet niet op 1 te drukken in top om individuele processor stats te zien). Hmmmm, je krabt even op je hoofd. Alleen cpu0 is 100% bezig. Daar heb je natuurlijk niet een mooi multicore systeem voor gekocht?!?! Je denkt er even over om je windows XP installatie CD in de cdrom speler te stoppen, maar besluit toch nog om eerst de man pagina van make te bekijken. Na wat aandachtig lezen, zie je daar de volgende regel staan:

-j [jobs], --jobs[=jobs]
    Specifies the number of jobs (commands) to run simultaneously. If there is more than one -j option, the last one is effective. If the -j option is given without an argument, make will not limit the number of jobs that can run simultaneously.

Ok, even proberen. Het systeem heeft dus in totaal 8 cores, dus make uitvoeren met 8 jobs zou het systeem optimaal moeten benutten:

make -j 8

Nu moet er een flinke grijns op je gezicht verschijnen. Je ziet de CC regels voorbij schieten en een paar minuten later staat je vers gebakken kernel voor je klaar.

Gebruiken van certificaten in Mutt

Tegenwoordig ontvangen we veel spam en andere "afval" e-mail. Hoe komen we erachter of de identiteit van de afzender eigenlijk wel klopt? Als je een gesigneerde e-mail met een digitale handtekening verstuurd, hoeft de ontvanger in ieder geval nooit aan jouw identiteit te twijfelen.

Om dit te realiseren zijn meerdere stappen nodig, waarvan de eerste het verkrijgen van een persoonlijk certificaat is. Aangezien we zoveel mogelijk met open-source producten willen werken, ga ik er hier vanuit dat het certificaat ook uit de open-source wereld verkregen wordt. Ga hiervoor naar de website van CACert en meld je aan.

Na het invullen van alle gegevens is het mogelijk om een e-mail certificaat aan te vragen en dit in je e-mail programma te gebruiken. In eerste instatie is dit een certificaat waarin niet je eigen naam opgenomen is, dat mag pas als je voldoende punten hebt verzameld door je identiteit te laten controleren door "Web of Trust" notaries. Hoe dit gedaan moet worden en waar je deze notaries kunt vinden staat uitgelegd op de site van CACert.

Maak eerst een prive sleutel aan met:

openssl genrsa -out private.key 4096

Genereer hieruit een 'certificate signing request', het verzoek tot het signeren van een te genereren certificaat:

openssl req -new -nodes -key private.key -out private.csr

en genereer op de CACert website een client certificaat met dit gegenereerde csr bestand (knip en plak het csr bestand in het juiste vakje, zet hiervoor het vinkje bij "Show advanced options" aan). Vergeet niet ook het "Add Single Sign On ID Information" bolletje aan te zetten. Hierna op "Next" klikken en het certificaat wordt gegenereerd.

Een certificaat ziet er bijvoorbeeld zo uit:

-----BEGIN CERTIFICATE-----
MIIGRDCCBCygAwIBAgIDBmrIMA0GCSqGSIb3DQEBBQUAMHkxEDAOBgNVBAoTB1Jv
b3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
.
.
-----END CERTIFICATE-----

Sla dit certificaat op (knippen en plakken) op een plek waar het veilig is (bijvoorbeeld private.crt) en zet de rechten goed (chmod 600 private.crt).

Haal bij CACert ook gelijk het "root" certificaat op en sla dit op als CACert_root.crt.

Het gegenereerde certificaat dient nu nog omgebouwd te worden tot een p12, een PKCS #12 bestand, wat staat voor "Public Key Cryptography Standards". Dit gaat met

openssl pkcs12 -export -in private.crt -inkey private.key  \
    -certfile privat.crt -out private.p12

Dit p12 bestand kunnen we nu gaan gebruiken in de e-mail client. Voor Mozilla Thunderbird is het echt recht-toe-recht-aan, importeer het certificaat en gebruik het om e-mail te signeren. Voor Mutt heeft dit nog wel wat extra voeten in aarde. Als eerste moet er gezorgd worden dat Mutt versie 1.5 gebruikt wordt, versie 1.4 en lager ondersteunen geen S/MIME. De versie van Mutt dient ook gecompileerd te zijn met S/MIME ondersteuning, wat te controleren is met:

mutt -v

Hierbij dient dan de compileer optie CRYPT_BACKEND_CLASSIC_SMIME aanwezig te zijn.

Als aan al deze eisen voldaan is, dan kan Mutt geconfigureerd worden om de certificaten te gaan gebruiken. Vul in de Mutt configuratie (of in een bestand dat gesourced wordt) de volgende regels in:

set smime_is_default
set smime_timeout=600
set crypt_autosign = yes
set crypt_replyencrypt = no
set crypt_replysign = no
set crypt_replysignencrypted = no
set crypt_verify_sig = no
set smime_default_key="12345678.0"
set smime_ca_location="~/.smime/roots.crt"
set smime_certificates="~/.smime/certificates"
set smime_keys="~/.smime/keys"
set smime_pk7out_command="openssl smime -verify -in %f -noverify -pk7out"
set smime_get_cert_command="openssl pkcs7 -print_certs -in %f"
set smime_get_signer_cert_command="openssl smime -verify -in %f -noverify -signer %c -out /dev/null"
set smime_get_cert_email_command="openssl x509 -in  %f -noout -email"
set smime_import_cert_command="smime_keys add_cert %f"
set smime_sign_as = "12345678.0"
set smime_encrypt_with="des3"
set smime_encrypt_command="openssl smime -encrypt -%a -outform DER -in %f %c"
set smime_sign_command="openssl smime -sign -signer %c -inkey %k -passin stdin -in %f -certfile %i -outform DER"
set smime_decrypt_command="openssl smime -decrypt  -passin stdin -inform DER -in %f -inkey %k -recip %c"
set smime_verify_command="openssl smime -verify -inform DER -in %s %C -content %f"
set smime_verify_opaque_command="\
openssl smime -verify -inform DER -in %s %C || \
openssl smime -verify -inform DER -in %s -noverify 2>/dev/null"

Op de plaats van de "12345678.0" moet straks nog de juiste hash-waarde worden ingevuld.

Hierna kun je het certificaat importeren in de Mutt S/MIME omgeving met:

smime init
smime_keys add_p12 private.p12

Vul het importeer wachtwoord in en het wachtwoord dat gebruikt gaat worden bij het signeren en encrypten van e-mails.

Wanneer smime_keys de melding Certificate: ~/.smime/certificates/xxxxxxxx.x already installed. geeft, dan is de versie van smime_keys waarschijnlijk niet correct. Dit is op te lossen door onderstaande regels (bij mij regel 461 en verder) te verwijderen

if (-e "$certificates_path/$$hashvalue") {
        print "\nCertificate: $certificates_path/$$hashvalue already installed.\n";
}
else {

Verwijder ook de bijbehorende eind } en sla het bestand op. Verwijder hierna de ~/.smime directory en probeer opnieuw het certificaat toe te voegen. Als dit gelukt is, geeft het smime_keys commando een hash voor het toegevoegde certificaat. Vul deze hash in de Mutt configuratie in, waar nu "12345678.0" staat.

Het volgende dat moet gebeuren is het importeren van de root certificaten. Helaas is het CACert root certificaat standaard niet opgenomen in de lijst van root-certificaten, maar we kunnen deze eenvoudig zelf toevoegen. Als eerste de standaard set root-certificaten. Zoek op het systeem naar het bestand ca-bundle.crt en onthoud het volledige pad (bij mij /usr/local/share/doc/mutt/samples/ca-bundle.crt) en geef de volgende commando's

smime_keys add_root /usr/local/share/doc/mutt/samples/ca-bundle.crt
smime_keys add_root CACert_root.crt

Vanaf nu is het mogelijk om e-mail berichten te signeren. Om de handtekening van berichten van anderen te kunnen verifieren moet nog aan Mutt verteld worden hoe dat gedaan moet worden. Vraag eerst aan Mutt wat de plaats is van het "mailcap" bestand en pas dit bestand aan

mutt -Q mailcap_path | awk -F'=' '{ gsub(/"/, ""); print $2 }'

en voeg de volgende regel aan het mailcap bestand toe: application/x-pkcs7-signature; openssl pkcs7 -in %s -inform der \ -noout -print_certs -text | less; needsterminal; copiousoutput;

Extraatje

Het is ook mogelijk om je certificaat te gebruiken als SSH inlog sleutel. Dit is een eenvoudig te realiseren en daarom staat het onderaan dit blog vermeld als extraatje.

Als eerste dient het pkcs12 certificaat omgezet te worden naar een .pem file in de SSH directory:

openssl pkcs12 -in private.p12 -out ~/.ssh/private.pem
chmod 600 ~/.ssh/private.pem

Genereer nu de publieke sleutel die op alle te benaderen hosts in de file ~/.ssh/authorized_keys of ~/.ssh/authorized_keys2 geplaatst wordt.

ssh-keygen -y private.pem

Dit ziet er dan ongeveer zo uit

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCm8XDlGI4........

Knip en plak deze publieke sleutel en bewaar hem goed (bijvoorbeeld in het bestand ~/.ssh/private.pem.pub)

Neem nu in het bestand ~/.ssh/config een configuratie op voor de host waarop je wilt inloggen

Host certest
    HostName certest.atcomputing.nl
    IdentityFile ~/.ssh/private.pem

en log in op de server certest om te controleren of alles naar behoren werkt.

Met het commando

openssl x509 -in private.pem -text

is te zien tot wanneer het certificaat geldig is en wanneer er dus weer een nieuw moet worden aangevraagd bij CACert.