IT operations are often perceived as a cost centre in businesses –a more or less trivial job to be run as leanly and cheaply as possible. Yet many system administrators (especially Unix administrators) are highly skilled and creative people who could deliver significant value to business operations, with the right tools and organization. There is, however, a cultural divide between Business and IT services that, over the last few years, has prompted the question: could IT and business be better aligned? One example of how this realization is changing IT is the mysterious phenomenon of Cloud Computing –an economic repackaging of existing technologies which can now be sold as a commodity.

In this talk, Mark Burgess asks why there is a disconnect and surveys current ideas about Business-IT alignment, suggesting ways in which system administrators can raise their level of importance within their organizations.

Do you want lightweight or feature full, how far do you want to go with your monitoring, just on OS level, or do you want to dig into your applications, do you want to know how many query per seconds your MySQL database is serving, or do you want to know about the internal state of your JBoss, or be triggered if the OOM killer will start working soon. This presentation will guide the audience through the different alternatives based on our experiences in the field. We will be looking both at alerting and trending and how easy or difficult it is to deploy such an environment. Monitoring the Network vs Monitoring Applications, or both?

Het belangrijkste doel van de RPM Package Manager, die op de meeste Linux-systemen wordt gebruikt, is om software packages op een gecontroleerde manier te (de)installaren. Dit is een zeer zinvolle taak, maar deze presentatie gaat nu eens niet over de gebruikelijke package management functies van RPM.

De RPM sofware kan ook worden (mis?)bruikt om systeemconfiguratie-taken te automatiseren voor een groep systemen. Dit kan worden gedaan door één of meer lokale RPM packages te maken die scripts en (delen van) configuratiefiles bevatten. Deze speciale packages bevatten niet alleen files, maar ze zorgen er ook voor dat er bepaalde systeemconfiguratie-acties worden uitgevoerd wanneer dat nodig is. Dit wordt gedaan door het trigger-script mechanisme, een krachtig feature van RPM dat niet erg vaak wordt gebruikt. Deze scripts worden uitgevoerd (ze worden "getriggerd") op het moment dat andere (!) RPM packages worden geïnstalleerd of verwijderd. Door in deze scripts configuratiefiles te wijzigen of andere systeembeheertaken te doen kan RPM worden gebruikt als een methode om vanuit een centraal punt systemen te configureren. En, belangrijker nog: wijzigingen kunnen binnen het netwerk worden verspreid door eenvoudigweg een configuratiepackage te updaten, dit in een lokale (yum) repository te zetten en het automatisch te laten oppakken door alle relevante systemen. En wanneer er op een systeem een nieuwe service wordt geïnstalleerd wordt deze automatisch correct geconfigueerd via de al aanwezige trigger-scripts.

De presentatie zal enkele "recepten" laten zien om de RPM configuratie-packages te genereren, zoals de package specificatie (RPM spec file), voorbeelden van scripts om configuratiefiles te wijzigen en hints om configuratie-informatie voor een netwerk te centraliseren.

Tenslotte zal getoond worden hoe het toevoegen of verwijderen van packages op systemen binnen een bestaand Linux-netwerk centraal geregeld kan worden. Dit kan worden bewerkstelligd via dezelfde RPM configuratie-packages, die dan bepaalde packages installeren of verwijderen via het RPM dependency-mechanisme.

Veel managementsystemen verzamelen logs op een centrale plaats. Maar er zijn veel meer mogelijkheden. Graag laten wij de nieuwste technieken zien waarbij meerdere logs van hetzelfde event met elkaar in verband worden gebracht, maar ook verschillende events aan elkaar worden gerelateerd.

Er bestaat een SIEM oplossing voor het leggen van unieke verbanden en inzichten tussen de verschillende logs van alle netwerkcomponenten en servers in een infrastructuur. In deze oplossing (van Juniper Networks) wordt apparatuur ondersteund van meer dan 100 vendor formaten waaronder Cisco, Microsoft, Checkpoint en ISS. Hierdoor kunnen system administrators sneller rapporteren en logs aanpakken op basis van automatische rapporten en signaleringen. Dit werkt zowel in real time als in de historie.

De belangrijkste pilaren van de SIEM oplossing zijn:

• Thread detection (het detecteren van bedreigingen die andere systemen missen)
• Log management (op het juiste moment de juiste bedreigingen rapporteren)
• Compliance
• IT efficiency (IT waarde achterhalen die nu niet gebruikt wordt)

Deze oplossing rapporteert en segmenteert op basis van de volgende criteria:

1. Geloofwaardigheid: Hoe geloofwaardig is het bewijs? Wat is de geloofwaardigheid van de getuigen? Zijn er meerdere getuigen van dezelfde aanval?
2. Relevantie: Gebaseerd op de waarde die aan netwerken en toebehoren wordt toegekend. Hoe relevant is deze bedreiging of overtreding voor jou? Of doet het zich voor in gebieden van het netwerk die niet zo belangrijk voor je zijn?
3. Severity: Hoe groot is de bedreiging van deze aanvaller, van dit netwerk, voor mijn onderneming? Dit wordt beïnvloed door de waarde-toekenning, taxaties, categorie (type) van aanslagen, de werkelijke kwetsbaarheid van de doelen en het aantal doelen.

Wat weet jij over OpenSSH, het programma dat je elke dag gebruikt? Kun jij OpenSSH configureren per bestemming? Weet jij hoe je met een SSH tunnel door een firewall raakt? Weet jij hoe je OpenSSH kunt gebruiken om veilig te surfen in een onveilige omgeving? Wat weet jij over remote port forwarding? Wist je dat je je eigen subsystemen kunt bouwen? Als je op minstens één van deze vragen “neen” moest antwoorden, is deze workshop iets voor jou.

To make systems administration easier, most sysads opt for strong levels of standardization as they call it. What they mean is to limit the variation and to decrease the number of different components like software applications and hardware configurations. Also they usually look at limiting the possibilities for users to increase security. From a governance point of view, this can be a good thing. However, when limiting the options, the chance for using the best of breed systems and applications decreases as well. The possibility for users to work comfortably can also be negatively impacted. This is generally not in the interest of the organisation the sysad is supporting in the first place.

How should standardization be used to support the organisation better without causing all sorts of headaches for the systems administrators? What are the do's and don'ts? How to deal with conflicting interest within organizations? This is what I will talk about. Making choices that are aimed at win-win, decreasing risk without decreasing workability. Subjects that will be covered are a.o.

• dealing with (conflicting) (non- functional) requirements
• how about architecture and frameworks
• choose better. How can we actually decide which choice is best?
• how to deal with Open Source
• how to deal with Open Standards
• external factors that influence our decisions

Een presentatie en discussie over de implementatie van het beheer van ongeveer 100 Linux desktops en een (klein) aantal (reken-)servers op de faculteit Wiskunde & Informatica van de Technische Universiteit Eindhoven.

Deze presentatie zal allereerst ingaan op het ontstaan van Linux beheer op de faculteit (jaren 1999/2000, rond Red Hat 6.2), en de toen geformuleerde eisen en wensen van de gebruikers: veelal researchers met specifieke wensen. De keuzes die daar gemaakt zijn liggen ten grondslag aan de huidige, zelfgeschreven, beheertools voor Fedora 12 en CentOS 5.4. Natuurlijk wordt er ook ingegaan op alle veranderingen in de loop der jaren. De architectuur en het gebruik van deze tools wordt daarna toegelicht en in het kort vergeleken met gangbare open source tools zoals cfengine/puppet en (in mindere mate) spacewalk. Ook worden er enkele voor- en nadelen van de zelfgeschreven tools aangestipt Tenslotte zal er kort ingegaan worden op de aanpassingen, aan zowel de tools als de processen, die verwacht worden in de toekomst en de impact die dit gaat hebben op het systeembeheer op de faculteit.

Thales is the largest defense company in the Netherlands. The IT department has 60 employees and takes care of more than 750 applications hosted on more than 400 servers. To be allowed to work on defense contracts, that may include working on classified material, we need an IT Facility Security Clearance, which is issued and audited by the MIVD (Dutch Military Intelligence and Security Department). That means security is really important. When talking about security most people mostly think about confidentiality, which is indeed important, but is only part of the story.

The fundamental principles of security are availability, integrity and confidentiality. To safeguard the availability and integrity of our information it is very important to have a monitoring system so we know something is wrong before our IT users call us. Or better still that we can prevent problems before they can happen. Nagios and MRTG are the tools that help us do that. We monitor our IT infrastructure using Nagios and MRTG now for a number of years. Basic monitoring is part of the standard setup of our servers, so this is now more or less an automated process.

After that we started to implement monitoring of our critical applications, which is more complex. No two applications are the same. However they often share a number of common components like a web interface (Apache Tomcat), a database (MySql, Oracle), a License server (FLEXlm). Most of these can be monitored using common available Nagios plug-ins. In case a plug-in is not available it is very easy to write your own because Nagios has a very simple and well documented plug-in interface.

This talk will introduce some basics of Nagios and I will tell how the tool is currently used by the IT department of Thales Hengelo.

Al decennia lang schrijven systeembeheerders zelf eigen tools om efficiënter te kunnen werken, zowel binnen een grote organisatie met duizenden machines in hun beheer, als binnen een kleine organisatie met slechts enkele machines. Van deze sofware wordt helaas slechts een klein deel gepubliceerd, waardoor het niet hergebruikt kan worden door andere systeembeheerders. Hierdoor ontwikkelen de tools zich niet verder tot een volwassen stuk software dat voor andere opstellingen geschikt zou zijn dan waar het in eerste instantie voor geschreven is. Dit, gecombineerd met het feit dat het copyright ervan vaak in handen is van de organisatie waarvoor de systeembeheerder werkt, zorgt ervoor dat binnen elke organisatie opnieuw wordt begonnen met het schrijven van hun eigen geweldige systeem op basis van zgn. "SSH-for-loops" en dergelijke.

Puppet is ontwikkeld om de gemeenschap van systeembeheerders te ondersteunen in het ontwikkelen en delen van volwassen tools, zodat niet iedereen opnieuw voor hetzelfde probleem staat om op te lossen.

Dit werkt als volgt:

• Puppet biedt een krachtig framework waarmee het merendeel van de taken van een systeembeheerder wordt versimpeld.
• Puppet gebruikt slechts één uniforme taal, welke eenvoudig te delen is net als elke andere (programma)code.

Dit betekent dat je als systeembeheerder efficiënter kan werken doordat Puppet de meeste -of wellicht alle- aspecten van het werk voor je uitvoert. Daarnaast kun je code van andere systeembeheerders downloaden om je nog beter te ondersteunen. Het merendeel van de Puppet implementaties gebruikt ten minste 1 of 2 modules welke door anderen zijn ontwikkeld en in Puppet Recipes zijn er nog veel meer beschikbaar.

De problematiek rondom het beheer van gebruikersaccounts, toegangscontrole en audit trails is algemeen bekend. Ondanks de vordering der techniek maakt men in de meeste bedrijfsnetwerken nog steeds gebruik van verouderde methodes die veelal op handwerk berusten.

FoxT's "BoKS Access Control" biedt in mijn ogen een elegante oplossing voor deze drie probleemgebieden. BoKS is cross-platform software die Role Based Identity Management en Role Based Access Control combineert met de mogelijkheid tot gedelegeerde super-user toegang en solide audit logging.

BoKS bestaat sinds de jaren negentig en wordt wereldwijd ingezet bij grote banken en multinationals. BoKS wordt binnen Nederland onder andere gebruikt binnen ING Bank en KPN Telecom.

De technologische ontwikkeling gaan razendsnel. VoIP is bezig met een opmars en ook op het gebied van telefonie wordt er veel ontwikkeld. Wie binnen zijn organisatie een nieuwe telefooncentrale plaatst of een oude vervangt heeft een ruime keuze aan leveranciers die zowel eigen oplossingen aanbieden als VoIP oplossingen. Organisaties kunnen er echter ook voor kiezen om gebruik te maken van Open Source Software. Vaak wordt er dan voor Asterisk gekozen, met FreePBX als beheerstool.

Tijdens deze presentatie wordt aan de hand van praktijkvoorbeelden ingegaan op de zaken die van belang zijn bij de overstap naar Asterisk. Niet alleen de centrale wordt vervangen, maar ook de toestellen. Er worden andere eisen gesteld aan de infrastructuur in het gebouw en er moeten keuzes worden gemaakt mbt. het beheer.

Aan bod komen andere ontwerp aspecten voor het netwerk, de keuzes voor de te gebruiken CODECs, het beheer en de configuratie van de toestellen en het koppelen van meerdere locaties.

Internet Service Provider (ISPs) always have strong requirements for their IT environment, e.g.:

• rapid provision new customers according to their needs
• dynamically adapt to customer requirements
• high-availability and fail-over for all systems avoiding single points of failure (SPOF)
• standardized and generic deployment (reproducible provisioning)
• standardized and automated configuration management
• simple and centralized mechanisms for system updates
• strong and robust backup + restore plus server-versioning
• detailed system- and service monitoring
• smart IP- and DNS-Management
• ... and more

Preferred all those different aspect centralized within a single management console. As a complete plug-able Data-Center Management Platform openQRM provides a proven and feature-rich open-source framework to standardized IT Infra-Structures in a generic and transparent way. The presentation focus on the different aspects of private Cloud Computing and how ISPs can take advantages of it based on an example use case of a Private openQRM Cloud. It deals with how to archive an agile, flexible and automated IT environment.

The openQRM Cloud provides a standardized, flexible and extensible "request system" mechanism for sysadmins and end-users to simple and fast get new server according their needs. Those systems are deployed using known-to-work server-templates. OpenQRM also provides the capability to easily exchange snapshots of development-, QA-, or even Production-servers during runtime without affecting the origin service. This means e.g. a development and the QA team can deploy a 1-to-1 copy of the production environment as their test-bed and even exchange snapshots of specific server for sanity checks.

Not only that openQRM offers a rich set of features and automatisms to manage modern Data-Centers in a scalable way but all the functionalities of openQRM are also exposed to End-Users via the openQRM Cloud plugin, so ... why not let your users provision and manage their systems on on their own via a private Cloud?

This talk will give you a little more insight into some of the hardware aspects related to modern systems. As most of you only view the systems environment from through the screen, and sometimes have not even seen the hardware in real life.

Getting more of an idea what is going on inside the machine, such as how do the signals "look" in the machine, aspects of cabling etc. will be discussed, as well as more physical stuff such as Radio Frequency.

The second part of the talk is dedicated to a piece of hardware recently aquired by the NLUUG: the conference wireless setup. I'll decribe the set- up and configuration of the new environment.

Als Linux-systeembeheerder kun je te maken krijgen met klachten over de performance. Je moet dan op zoek naar de oorzaak: welke resource wordt overbelast, wanneer, hoe vaak, en waardoor. Tijdens je onderzoek zul je steeds verder in moeten zoomen. Welke resource(s) zijn overbelast? Door welke processen? En eventueel nog verder: welk deel binnen het proces is verantwoordelijk. Pas als je weet wat er aan de hand is, kun je beslissen wat er moet worden gedaan om de situatie te verbeteren. Zomaar hardware bijkopen is meestal niet de oplossing: “Extra ijzer, niets wijzer”.

Het onderzoek naar de oorzaak van de performanceproblemen vereist dat je een tool hebt dat belasting van de vier belangrijke resources CPU, geheugen, disks en netwerk zowel op systeem niveau laat zien, als ook per proces. Hierbij mag in de boekhouding uiteraard geen “leakage” zitten: als de CPU 90% bezet is, moet de som van CPU gebruik door de processen ook 90% opleveren.

atop is een tool dat probeert een zo volledig mogelijk beeld te geven van de belasting van het systeem. Daarbij wordt niet alleen op systeem niveau bijgehouden hoe het zit met de belasting, maar ook per proces wordt bijgehouden hoeveel de bijdrage is van dit proces in de belasting op gebied van CPU, geheugen, disk I/O en netwerk. Daarbij kan atop niet alleen het hier en nu bekijken, maar ook laten zien wat er op een bepaald moment in het verleden speelde.

Deze presentatie zal laten zien hoe je met atop kunt meten, en hoe je atop aan je eigen wensen kunt aanpassen.

For the distribution, storing and analyzing of the data from the LHC (Large Hadron Collider) a global collaboration was setup linking large grid infrastructures and computing centers together to build the WLCG (Worldwide LHC Computing grid). The WLCG is a tiered infrastructure with a T0, which is CERN (the Machine), 11 T1s and a large number of T2s. SARA with neighbouring institute Nikhef participate in the WLCG and form the Dutch Tier1 for the LHC.

When running production the LHC generates about 15PB per year. A T1 is next to the T0, the primary site to permanently store, process and analyze about 1/10th of the produced data capacity, which is about 1-1,5PB per year. SARA and Nikhef have been building up the last 5-6 years the infrastructure of the Dutch T1. Currently the shared infrastructure of the T1 consists of a compute cluster about 3000+ cores, online storage of about 4PB, about 1.5 PB offline tape storage, a small cluster running a large number of different grid services built around a 10GE network infrastructure.

In this talk, I will speak about aspects of setting up and maintaining this complex infrastructure, datacenter planning, backups, monitoring of the availabilty and the performance and how to face out components. But I also want to give some highlights in collaborating in a worldwide project.

With more and more services and applications running on your average server, upgrading the operating system and application software becomes trickier and larger service windows are needed performing these upgrades.

Over the last four years the author has searched for means and methods to keep software up to date with minimum downtime and inconvenience for users and maximum consistency. The result is a model which combines the strength of NanoBSD, ZFS and jails to build servers where application upgrades result in downtime of only a few seconds and kernel upgrades only need the time to reboot without installing in (tampering with) the running system. This system is in production now for several months on 6 to 8 servers at four different sites.

In deze presentatie introduceren wij een voorbeeld van het gebruik van de Google App Engine. Door middel van een case beschrijving wordt getoond hoe een ketenorganisatie eerst werkte met verschillende informatie systemen die niet gekoppeld waren. Hierdoor was het voor medewerkers moeilijk om de juiste gegevens te achterhalen omdat deze niet geïntegreerd werden aangeboden.

Onze oplossing die we zullen demonstreren is een cloud applicatie gebaseerd op de technologie van de Google App Engine. Medewerkers kunnen de systemen er nu eenvoudig mee ontsluiten en gezamenlijk gebruiken met andere cloud services (zoals plattegronden, agenda en OV informatie). We demonsteren met name de architectuur, de deployment en het beheer van de Google App Engine.

"Some call this phenomenon devops, others agile system administration Truth is that agile techniques used in development have an impact on the way operations organizes it work. Similar, operations and sysadmins are becoming programmers because of the virtualization and automation trend where everything is managed through an API. So if you are a developer with a interest for system administration, or a sysadmin interested in development, join us on the first conference that focuses on bringing the best of both worlds together."

That's how DevopsDays09 was announced last Summer. It's a new movement, it's the way lots of SysAdmin people have been working, work, or should work.

Having worked this way for a couple of years now, and trying to promote this way of working, my Talk will summarise the ideas behind Devops, Devministration or whatever you want to name it.

Synctool is een softwarepakket voor het beheren van computerclusters, vergelijkbaar met Cfengine en Puppet. Het is ontwikkeld door Walter de Jong, systeemexpert bij SARA, voor het beheer van de nationale supercomputer Huygens. Daarnaast wordt het in toenemende mate gebruikt voor diverse andere clusters, zowel binnen SARA als daarbuiten. Synctool heeft enkele sterke punten:

• Het is snel (in circa een uur) te leren;
• Gebouwd in Python met gebruik van rsync en ssh, dus bekende technieken;
• Geen aparte programmeertaal, hoogstens wat shell scripting naar behoefte;
• Slechts één klein configuratiebestand;
• Zonder parameters geeft synctool alleen een preview van wat er gedaan zou worden;
• Gerelateerde files staan in synctool in dezelfde directory, en niet verspreid over meerdere directories zoals bij cfengine.

Writing a good autoresponder for email is not difficult, but there are a lot of trivial things that get in the way of making it easy. In this talk I want to show what you have to take into account and keep in mind writing an autoresponder and tell how I implemented this for our own autoresponder at Loohuis Consulting. I will also briefly go into how various systems generate their mails and how you can help making it easier for everybody who wants to write a proper autoresponder.

WARNING: In this talk I will state the obvious!