HtmlToText
journey in a software world… rss blog about bio software contributions archives bootstrapping windows servers with puppet 11 jan 2014 | comments all started a handful of months ago, when it appeared that we’d need to build some of our native software on windows . before that time, all our desktop software at days of wonder was mostly cross-platform java code that could be cross-compiled on linux. unfortunately, we badly needed a windows build machine. in this blog post, i’ll tell you the whole story from my zero knowledge of windows administration to an almost fully automatized windows build machine image construction. jenkins but, first let’s digress a bit to explain in which context we operate our builds. our ci system is built around jenkins, with a specific twist. we run the jenkins master on our own infrastructure and our build slaves on aws ec2. the reason behind this choice is out of the scope of this article (but you can still ask me, i’ll happily answer). so, we’re using the jenkins ec2 plugin , and a revamped by your servitor jenkins s3 plugin . we produce somewhat large binary artifacts when building our client software, and the bandwidth between ec2 and our master is not that great (and expensive), so using the aforementioned patch i contributed, we host all our artifacts into s3, fully managed by our out-of-aws jenkins master. the problem i faced when starting to explore the intricate world of windows in relation with jenkins slave, is that we wanted to keep the linux model we had: on-demand slave spawned by the master when scheduling a build. unfortunately the current state of the jenkins ec2 plugin only supports linux slave. enter winrm and winrs the ec2 plugin for linux slave works like this: it starts the slave using an internal scp implementation it copies ‘slave.jar’ which implements the client jenkins remoting protocol using an internal ssh implementation, it executes java -jar slave.jar . the stdin and stdout of the slave.jar process is then connected to the jenkins master through an ssh tunnel. now, jenkins does its job (basically sending more jars, classes) at this stage the slave is considered up i needed to replicate this behavior. in the windows world, ssh is inexistent. you can find some native implementation (like freesshd or some other commercial ones), but all that options weren’t easy to implement, or simply non-working. in the windows world, remote process execution is achieved through the windows remote management which is called winrm for short. winrm is an implementation of the wsman specifications. it allows to access the windows management instrumentation to get access to hardware counters (ala snmp or ipmi for the unix world). one component of winrm is winrs : windows remote shell . this is the part that allows to run remote commands. recent windows version (at least since server 2003) are shipped with winrm installed (but not started by default). winrm is an http/soap based protocol. by default, the payload is encrypted if the protocol is used in a domain controller environment (in this case, it uses kerberos), which will not be our case on ec2. digging, further, i found two client implementations: xebialabs overthere written in java winrb , written in ruby. i started integrating overthere into the ec2-plugin but encountered several incompatibilities, most notably overthere was using a more recent dependency on some libraries than jenkins itself. i finally decided to create my own winrm client implementation and released windows support for the ec2 plugin . this hasn’t been merged upstream, and should still be considered experimental. we’re using this version of the plugin for about a couple of month and it works, but to be honest winrm doesn’t seem to be as stable as ssh would be. there are times the slave is unable to start correctly because winrm abruptly stops working (especially shortly after the machine boots). winrm, the bootstrap so all is great, we know how to execute commands remotely from jenkins. but that’s not enough for our sysadmin needs. especially we need to be able to create a windows ami that contains all our software to build our own applications. since i’m a long time puppet user (which you certainly noticed if you read this blog in the past), using puppet to configure our windows build slave was the only possiblity. so we need to run puppet on a windows base ami, then create an ami from there that will be used for our build slaves. and if we can make this process repeatable and automatic that’d be wonderful. in the linux world, this task is usually devoted to tools like packer or veewee (which btw supports provisioning windows machines). unfortunately packer which is written in go doesn’t yet support windows, and veewee doesn’t support ec2. that’s the reason i ported the small implementation i wrote for the jenkins ec2 plugin to a winrm go library . this was the perfect pet project to learn a new language :) windows base ami so, starting with all those tools, we’re ready to start our project. but there’s a caveat: winrm is not enabled by default on windows. so before automating anything we need to create a windows base ami that would have the necessary tools to further allow automating installation of our build tools. windows boot on ec2 there’s a service running on the aws windows ami called ec2config that does the following at the first boot: set a random password for the ‘administrator’ account generate and install the host certificate used for remote desktop connection. execute the specified user data (and cloud-init if installed) on first and subsequent boot, it also does: it might set the computer host name to match the private dns name it configures the key management server (kms), check for windows activation status, and activate windows as necessary. format and mount any amazon ebs volumes and instance store volumes, and map volume names to drive letters. some other administrative tasks one thing that is problematic with windows on ec2 is that the administrator password is unfortunately defined randomly at the first boot. that means to further do things on the machine (usually using remote desktop to administer it) you need to first know it by asking aws (with the command-line you can do: aws ec2 get-password-data ). next, we might also want to set a custom password instead of this dynamic one. we might also want to enable winrm and install several utilities that will help us later. to do that we can inject specific ami user-data at the first boot of the windows base ami. those user-data can contain one or more cmd.exe or powershell scripts that will get executed at boot. i created this windows bootstrap gist (actually i forked and edited the part i needed) to prepare the slave. first bootstrap first, we’ll create a windows security group allowing incoming winrm, smb and rdp: 1 2 3 4 5 6 7 aws ec2 create-security-group --group-name "windows" --description "remote access to windows instances" # winrm aws ec2 authorize-security-group-ingress --group-name "windows" --protocol tcp --port 5985 --cidr <yourip>/32 # incoming smb/tcp aws ec2 authorize-security-group-ingress --group-name "windows" --protocol tcp --port 445 --cidr <yourip>/32 # rdp aws ec2 authorize-security-group-ingress --group-name "windows" --protocol tcp --port 3389 --cidr <yourip>/32 now, let’s start our base image with the following user-data (let’s put it into userdata.txt): 1 2 3 4 <powershell> set-executionpolicy unrestricted icm $executioncontext.invokecommand.newscriptblock((new-object net.webclient).downloadstring('https://gist.github.com/masterzen/6714787/raw')) -argumentlist "verysecret" </powershell> this powershell script will download the windows bootstrap gist and execute it, passing the desired administrator password. next we launch the instance: 1 aws ec2 run-instances --image-id ami-4524002c --instance-type m1.small --security-groups windows --key-name <yourkey> --u
Informations Whois
Whois est un protocole qui permet d'accéder aux informations d'enregistrement.Vous pouvez atteindre quand le site Web a été enregistré, quand il va expirer, quelles sont les coordonnées du site avec les informations suivantes. En un mot, il comprend ces informations;
%%
%% This is the AFNIC Whois server.
%%
%% complete date format : DD/MM/YYYY
%% short date format : DD/MM
%% version : FRNIC-2.5
%%
%% Rights restricted by copyright.
%% See https://www.afnic.fr/en/products-and-services/services/whois/whois-special-notice/
%%
%% Use '-h' option to obtain more information about this service.
%%
%% [2600:3c03:0000:0000:f03c:91ff:feae:779d REQUEST] >> masterzen.fr
%%
%% RL Net [##########] - RL IP [#########.]
%%
domain: masterzen.fr
status: ACTIVE
hold: NO
holder-c: ANO00-FRNIC
admin-c: ANO00-FRNIC
tech-c: OVH5-FRNIC
zone-c: NFC1-FRNIC
nsl-id: NSL20034-FRNIC
registrar: OVH
Expiry Date: 11/01/2019
created: 11/01/2008
last-update: 11/01/2018
source: FRNIC
ns-list: NSL20034-FRNIC
nserver: dns11.ovh.net
nserver: ns11.ovh.net
source: FRNIC
registrar: OVH
type: Isp Option 1
address: 2 Rue Kellermann
address: 59100 ROUBAIX
country: FR
phone: +33 8 99 70 17 61
fax-no: +33 3 20 20 09 58
e-mail: support@ovh.net
website: http://www.ovh.com
anonymous: NO
registered: 21/10/1999
source: FRNIC
nic-hdl: ANO00-FRNIC
type: PERSON
contact: Ano Nymous
remarks: -------------- WARNING --------------
remarks: While the registrar knows him/her,
remarks: this person chose to restrict access
remarks: to his/her personal data. So PLEASE,
remarks: don't send emails to Ano Nymous. This
remarks: address is bogus and there is no hope
remarks: of a reply.
remarks: -------------- WARNING --------------
registrar: OVH
changed: 11/01/2008 anonymous@anonymous
anonymous: YES
obsoleted: NO
source: FRNIC
nic-hdl: OVH5-FRNIC
type: ROLE
contact: OVH NET
address: OVH
address: 140, quai du Sartel
address: 59100 Roubaix
country: FR
phone: +33 8 99 70 17 61
e-mail: tech@ovh.net
trouble: Information: http://www.ovh.fr
trouble: Questions: mailto:tech@ovh.net
trouble: Spam: mailto:abuse@ovh.net
admin-c: OK217-FRNIC
tech-c: OK217-FRNIC
notify: tech@ovh.net
registrar: OVH
changed: 11/10/2006 tech@ovh.net
anonymous: NO
obsoleted: NO
source: FRNIC
REFERRER http://www.nic.fr
REGISTRAR AFNIC
SERVERS
SERVER fr.whois-servers.net
ARGS masterzen.fr
PORT 43
TYPE domain
RegrInfo
DISCLAIMER
%
% This is the AFNIC Whois server.
%
% complete date format : DD/MM/YYYY
% short date format : DD/MM
% version : FRNIC-2.5
%
% Rights restricted by copyright.
% See https://www.afnic.fr/en/products-and-services/services/whois/whois-special-notice/
%
% Use '-h' option to obtain more information about this service.
%
% [2600:3c03:0000:0000:f03c:91ff:feae:779d REQUEST] >> masterzen.fr
%
% RL Net [##########] - RL IP [#########.]
%
REGISTERED yes
ADMIN
HANDLE ANO00-FRNIC
TYPE PERSON
CONTACT Ano Nymous
REMARKS
-------------- WARNING --------------
While the registrar knows him/her,
this person chose to restrict access
to his/her personal data. So PLEASE,
don't send emails to Ano Nymous. This
address is bogus and there is no hope
of a reply.
-------------- WARNING --------------
SPONSOR OVH
CHANGED 2008-01-11
ANONYMOUS YES
OBSOLETED NO
SOURCE FRNIC
TECH
HANDLE OVH5-FRNIC
TYPE ROLE
CONTACT OVH NET
ADDRESS
OVH
140, quai du Sartel
59100 Roubaix
COUNTRY FR
PHONE +33 8 99 70 17 61
EMAIL tech@ovh.net
TROUBLE
Information: http://www.ovh.fr
Questions: mailto:tech@ovh.net
Spam: mailto:abuse@ovh.net
ADMIN-C OK217-FRNIC
TECH-C OK217-FRNIC
NOTIFY tech@ovh.net
SPONSOR OVH
CHANGED 2006-10-11
ANONYMOUS NO
OBSOLETED NO
SOURCE FRNIC
OWNER
HANDLE ANO00-FRNIC
TYPE PERSON
CONTACT Ano Nymous
REMARKS
-------------- WARNING --------------
While the registrar knows him/her,
this person chose to restrict access
to his/her personal data. So PLEASE,
don't send emails to Ano Nymous. This
address is bogus and there is no hope
of a reply.
-------------- WARNING --------------
SPONSOR OVH
CHANGED 2008-01-11
ANONYMOUS YES
OBSOLETED NO
SOURCE FRNIC
DOMAIN
STATUS ACTIVE
HOLD NO
SPONSOR OVH
EXPIRY DATE 11/01/2019
CREATED 2008-01-11
CHANGED 2018-01-11
SOURCE FRNIC
HANDLE NSL20034-FRNIC
NSERVER
DNS11.OVH.NET 213.251.188.130
NS11.OVH.NET 213.251.128.130
NAME masterzen.fr
Go to top
masterzen.fr rapport :
Visitez le site