12:01 a.m.
Hello,
As promised and hopefully in time for tomorrows meeting I present to you
some basic puppet classes and modules to help us manage our infra. I
created a github repo[1] with some very basic classes.
Some things I'm unsure about:
- I'm not sure if a dash ('-') is allowed in the class name. It works
but github highlights it weird.
- I think publishing the public key is no problem (they're public after
all), but if something like the debian SSH fiasco[2] would happen
again we might be at risk.
- It's very basic, just ensure users exist and sudo is set up. We can do
much more, but what do we want?
In other words, here's what I worked on and I'd love to hear what you
think.
[1]: https://github.com/ekohl/ovirt-infra-puppet
[2]: http://www.debian.org/security/2008/dsa-1571
1:29 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/13/2012 03:01 PM, Ewoud Kohl van Wijngaarden wrote:
- It's very basic, just ensure users exist and sudo is set up.
We
can do much more, but what do we want?
Not sure what makes sense, thus some random ideas:
* Can we further strip out extra packages, or is that best handled in
the original install image or kickstart script?
* Firewall rules, sshd rules - I like to put sshd on a non-standard
port, such as 108, to minimize noise in the logwatch.
* Enable a remote backup solution for any data sources.
* ...
- - Karsten, still thinking
- --
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFQKY3Z2ZIOBq0ODEERAmp1AJ4/hXN9G6K7cm1oPmxiIup3FWF/jACfXc2N
A7DVfSIZ4Ss8szGrFCfOu88=
=B0dY
-----END PGP SIGNATURE-----
12:16 p.m.
On Mon, Aug 13, 2012 at 04:29:29PM -0700, Karsten 'quaid' Wade wrote:
On 08/13/2012 03:01 PM, Ewoud Kohl van Wijngaarden wrote:
> - It's very basic, just ensure users exist and sudo is set up. We
> can do much more, but what do we want?
Not sure what makes sense, thus some random ideas:
* Can we further strip out extra packages, or is that best handled in
the original install image or kickstart script?
I think this is better handled in
install image / kickstart, but if you
have specific packages you don't want installed we can list those.
* Firewall rules, sshd rules - I like to put sshd on a non-standard
port, such as 108, to minimize noise in the logwatch.
I was thinking the same, at
least disable password authentication for
SSH, disable root etc.
* Enable a remote backup solution for any data sources.
I think
we first have to decide on a backup solution, but in time yes.
* ...
Maybe it's best to start with something small that
provides a working
solution, set up a puppet master either with or without foreman and get
the git repo into gerrit.
4:21 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/14/2012 03:16 AM, Ewoud Kohl van Wijngaarden wrote:
On Mon, Aug 13, 2012 at 04:29:29PM -0700, Karsten 'quaid'
Wade
wrote:
> On 08/13/2012 03:01 PM, Ewoud Kohl van Wijngaarden wrote:
>
>> - It's very basic, just ensure users exist and sudo is set up.
>> We can do much more, but what do we want?
>
> Not sure what makes sense, thus some random ideas:
>
> * Can we further strip out extra packages, or is that best
> handled in the original install image or kickstart script?
I think this is better handled in install image / kickstart, but if
you have specific packages you don't want installed we can list
those.
> * Firewall rules, sshd rules - I like to put sshd on a
> non-standard port, such as 108, to minimize noise in the
> logwatch.
I was thinking the same, at least disable password authentication
for SSH, disable root etc.
Along with disabling root login, we can also load in the public keys
of the Infra team in to their user accounts, so people can ssh + sudo
directly after the host is up.
- - Karsten
> * Enable a remote backup solution for any data sources.
I think we first have to decide on a backup solution, but in time
yes.
> * ...
Maybe it's best to start with something small that provides a
working solution, set up a puppet master either with or without
foreman and get the git repo into gerrit.
_______________________________________________ Infra mailing list
Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
- --
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFQKl7r2ZIOBq0ODEERAj9lAJ9av4GtnvSP32xcI0q0AfmyogBoGgCgwoJ9
AHoeCD8aoWpyliI77JLVWto=
=f8ht
-----END PGP SIGNATURE-----
9:35 a.m.
----- Original Message -----
From: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
To: infra(a)ovirt.org
Sent: Tuesday, August 14, 2012 1:01:55 AM
Subject: Puppet proposal
Hello,
As promised and hopefully in time for tomorrows meeting I present to
you
some basic puppet classes and modules to help us manage our infra. I
created a github repo[1] with some very basic classes.
Some things I'm unsure about:
- I'm not sure if a dash ('-') is allowed in the class name. It works
but github highlights it weird.
- I think publishing the public key is no problem (they're public
after
all), but if something like the debian SSH fiasco[2] would happen
again we might be at risk.
- It's very basic, just ensure users exist and sudo is set up. We can
do
much more, but what do we want?
for starts we need to able to install a jenkins slave with all it's deps, this means:
1. installing all packages for making rpms (autoconf,make,gcc,python-*,etc...)
2. installing the jenkins-slave deamon (for running jnlp)
3. jenkins user + home dir..
4. openjdk-1.7.0-java-devel
5. selinux settings.. .
and basically every thing we stumble upon when installing a new slave.
other things might be installing system services on all vms like:
- log collector
- backup
- cleanup
- monitoring
In other words, here's what I worked on and I'd love to hear what you
think.
[1]: https://github.com/ekohl/ovirt-infra-puppet
[2]: http://www.debian.org/security/2008/dsa-1571
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
12:11 p.m.
On Tue, Aug 14, 2012 at 03:35:22AM -0400, Eyal Edri wrote:
Ewoud Kohl van Wijngaarden wrote:
> As promised and hopefully in time for tomorrows meeting I present to
> you
> some basic puppet classes and modules to help us manage our infra. I
> created a github repo[1] with some very basic classes.
>
> Some things I'm unsure about:
> - I'm not sure if a dash ('-') is allowed in the class name. It works
> but github highlights it weird.
> - I think publishing the public key is no problem (they're public
> after
> all), but if something like the debian SSH fiasco[2] would happen
> again we might be at risk.
> - It's very basic, just ensure users exist and sudo is set up. We can
> do
> much more, but what do we want?
for starts we need to able to install a jenkins slave with all it's deps, this
means:
1. installing all packages for making rpms (autoconf,make,gcc,python-*,etc...)
I'll add these, but please expand python-*
2. installing the jenkins-slave deamon (for running jnlp)
I'll look into this.
3. jenkins user + home dir..
check
4. openjdk-1.7.0-java-devel
check
5. selinux settings.. .
Right now vdsm unit tests have sudo
permission to call setenforce. Not
what we want in the long term, but I was told the unit tests need this.
and basically every thing we stumble upon when installing a new
slave.
other things might be installing system services on all vms like:
- log collector
- backup
- cleanup
- monitoring
I think we'll add these as they come along.
12:25 p.m.
------=_Part_4471966_1306959306.1344939939797
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
----- Original Message -----
From: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
To: "Eyal Edri" <eedri(a)redhat.com>
Cc: infra(a)ovirt.org
Sent: Tuesday, August 14, 2012 1:11:20 PM
Subject: Re: Puppet proposal
On Tue, Aug 14, 2012 at 03:35:22AM -0400, Eyal Edri wrote:
> Ewoud Kohl van Wijngaarden wrote:
> > As promised and hopefully in time for tomorrows meeting I present
> > to
> > you
> > some basic puppet classes and modules to help us manage our
> > infra. I
> > created a github repo[1] with some very basic classes.
> >
> > Some things I'm unsure about:
> > - I'm not sure if a dash ('-') is allowed in the class name. It
> > works
> > but github highlights it weird.
> > - I think publishing the public key is no problem (they're public
> > after
> > all), but if something like the debian SSH fiasco[2] would
> > happen
> > again we might be at risk.
> > - It's very basic, just ensure users exist and sudo is set up. We
> > can
> > do
> > much more, but what do we want?
>
> for starts we need to able to install a jenkins slave with all it's
> deps, this means:
>
> 1. installing all packages for making rpms
> (autoconf,make,gcc,python-*,etc...)
I'll add these, but please expand python-*
python-devel-2.7.3-7.2.fc17.x86_64
python-pep8-1.0.1-1.fc17.noarch
libxml2-python-2.7.8-7.fc17.x86_64
python-nose-1.1.2-2.fc17.noarch
python-dateutil-1.5-3.fc17.noarch
python-paramiko-1.7.7.1-2.fc17.noarch
python-cheetah-2.4.4-2.fc17.x86_64
sanlock-python-2.4-2.fc17.x86_64
libvirt-python-0.9.13-3.fc17.x86_64
python-cherrypy-3.2.2-1.fc17.noarch
best thing will be to have a new vm and try to run make rpm on it (for vdsm &
ovirt-engine) and we'll see what's missing.
or just to check the spec files ..
> 2. installing the jenkins-slave deamon (for running jnlp)
I'll look into this.
i have a deamon i've written already - attached.
> 3. jenkins user + home dir..
check
> 4. openjdk-1.7.0-java-devel
check
> 5. selinux settings.. .
Right now vdsm unit tests have sudo permission to call setenforce.
Not
what we want in the long term, but I was told the unit tests need
this.
> and basically every thing we stumble upon when installing a new
> slave.
>
> other things might be installing system services on all vms like:
> - log collector
> - backup
> - cleanup
> - monitoring
I think we'll add these as they come along.
------=_Part_4471966_1306959306.1344939939797
Content-Type: application/x-shellscript; name=jenkins-slave
Content-Disposition: attachment; filename=jenkins-slave
Content-Transfer-Encoding: base64
IyEvYmluL2Jhc2gKIwojIGplbmtpbnMtc2xhdmUJCiMJVGhpcyBzaGVsbCBzY3JpcHQgcnVucyBq
ZW5raW5zIHNsYXZlIHZpYSBKTkxQLgojCiMgRGVmYXVsdC1TdGFydDoJMyA1CiMgRGVmYXVsdC1T
dG9wOiAgICAgICAgIDAgMSAyIDYKIyBEZXNjcmlwdGlvbjogc2xhdmUgSk5MUCBkYWVtb24gZm9y
IGplbmtpbnMuIAoKIyBTb3VyY2UgZnVuY3Rpb24gbGlicmFyeS4KLiAvZXRjL2luaXQuZC9mdW5j
dGlvbnMKCnByb2c9amVua2lucy1zbGF2ZQpzbGF2ZW5hbWU9YGhvc3RuYW1lICB8Y3V0IC1kIi4i
IC1mMWAKamVua2luc19tYXN0ZXJfdXJsPWh0dHA6Ly9qZW5raW5zLm92aXJ0Lm9yZwoKSkVOS0lO
U19VU0VSPSJqZW5raW5zIgpKRU5LSU5TX1NMQVZFX1BJRF9GSUxFPSIvdmFyL3J1bi9qZW5raW5z
LXNsYXZlLnBpZCIKSkFWQV9DTUQ9Ii91c3IvYmluL2phdmEgLWphciAvdmFyL2xpYi9qZW5raW5z
L3NsYXZlLmphciAtam5scFVybCAkamVua2luc19tYXN0ZXJfdXJsL2NvbXB1dGVyLyRzbGF2ZW5h
bWUvc2xhdmUtYWdlbnQuam5scCIKI2NtZD0iL3Vzci9iaW4vamF2YSAtamFyIC92YXIvbGliL2pl
bmtpbnMvc2xhdmUuamFyIC1qbmxwVXJsICRqZW5raW5zX21hc3Rlcl91cmwvY29tcHV0ZXIvJHNs
YXZlbmFtZS9zbGF2ZS1hZ2VudC5qbmxwIgoKbG9ja2ZpbGU9L3Zhci9sb2NrL3N1YnN5cy8kcHJv
ZwpSRVRWQUw9MAoKY2FzZSAiJDEiIGluCglzdGFydCkgCgkJIyBTdGFydCBkYWVtb25zLgoJCWVj
aG8gLW4gJCJTdGFydGluZyAkcHJvZzogIgoJCWRhZW1vbiAtLXVzZXIgJEpFTktJTlNfVVNFUiAt
LXBpZGZpbGUgIiRKRU5LSU5TX1NMQVZFX1BJRF9GSUxFIiAkSkFWQV9DTUQgJiA+IC9kZXYvbnVs
bAoJCVJFVFZBTD0kPwoJCWlmIFsgJFJFVFZBTCA9IDAgXTsgdGhlbgoJCSAgICBzdWNjZXNzCgkJ
ICAgIGVjaG8gPiAiJEpFTktJTlNfU0xBVkVfUElEX0ZJTEUiICAjIGp1c3QgaW4gY2FzZSB3ZSBm
YWlsIHRvIGZpbmQgaXQKCQkgICAgTVlfU0VTU0lPTl9JRD1gL2Jpbi9wcyBoIC1vIHNlc3MgLXAg
JCRgCgkJICAgICMgZ2V0IFBJRAoJCSAgICAvYmluL3BzIGh3dyAtdSAiJEpFTktJTlNfVVNFUiIg
LW8gc2VzcyxwcGlkLHBpZCxjbWQgfCBcCgkJICAgIHdoaWxlIHJlYWQgc2VzcyBwcGlkIHBpZCBj
bWQ7IGRvCgkJCVsgIiRwcGlkIiA9IDEgXSB8fCBjb250aW51ZQoJCQllY2hvICIkY21kIiB8IGdy
ZXAgICJqbmxwIiA+IC9kZXYvbnVsbAoJCQlbICQ/ID0gMCBdIHx8IGNvbnRpbnVlCgkJCSMgZm91
bmQgYSBQSUQKCQkJZWNobyAkcGlkID4gIiRKRU5LSU5TX1NMQVZFX1BJRF9GSUxFIgoJCSAgICBk
b25lCgkJZWxzZQoJCQlmYWlsdXJlCgkJZmkKCQllY2hvCgkJOzsKCglzdG9wKQoJCWVjaG8gLW4g
IlNodXR0aW5nICRwcm9nICIKCQlraWxscHJvYyBqZW5raW5zLXNsYXZlCgkJUkVUVkFMPSQ/CgkJ
ZWNobwoJCTs7CgoJcmVzdGFydCkKCQkkMCBzdG9wCgkJJDAgc3RhcnQKCQk7OwoKCXN0YXR1cykK
CQlzdGF0dXMgamVua2lucy1zbGF2ZQoJCVJFVFZBTD0kPwoJCTs7CgkqKQoJCWVjaG8gIlVzYWdl
OiAkMCB7c3RhcnR8c3RvcHxzdGF0dXN8dHJ5LXJlc3RhcnR8cmVzdGFydHxmb3JjZS1yZWxvYWR8
cmVsb2FkfHByb2JlfSIKCQkJZXhpdCAxCgkJCTs7Cgplc2FjCmV4aXQgJFJFVFZBTAoK
------=_Part_4471966_1306959306.1344939939797--
4:24 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/14/2012 03:25 AM, Eyal Edri wrote:
i have a deamon i've written already - attached.
Do we have a git repo for the Infra team yet? I know we could have
Puppet manifests in its own repo, but we have other version control
needs. Maybe one repo?
- - Karsten
- --
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFQKl+J2ZIOBq0ODEERArmdAKCH4ro2WnKzyFu+TX6g8zlIdn5xWQCgxfVF
5KbY33AL3uVuGOJqQLlUdSc=
=2cy5
-----END PGP SIGNATURE-----
5:41 p.m.
----- Original Message -----
From: "Karsten 'quaid' Wade"
<kwade(a)redhat.com>
To: infra(a)ovirt.org
Sent: Tuesday, August 14, 2012 5:24:09 PM
Subject: Re: Puppet proposal
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/14/2012 03:25 AM, Eyal Edri wrote:
>
> i have a deamon i've written already - attached.
Do we have a git repo for the Infra team yet? I know we could have
Puppet manifests in its own repo, but we have other version control
needs. Maybe one repo?
i recommend one repo for puppet classes. ('puppet')
we can publish it to community also, so people can contribute puppet classes we well.
i still think we need a separate 'jenkins' repo for all jenkins code, for personal
exp using complex jenkins code in jobs.
but i won't object to have a single repo for starts with subdirectories (/jenkins
/puppet /foreman)
E.
- - Karsten
- --
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFQKl+J2ZIOBq0ODEERArmdAKCH4ro2WnKzyFu+TX6g8zlIdn5xWQCgxfVF
5KbY33AL3uVuGOJqQLlUdSc=
=2cy5
-----END PGP SIGNATURE-----
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
11:05 p.m.
On 08/14/2012 11:41 AM, Eyal Edri wrote:
----- Original Message -----
> From: "Karsten 'quaid' Wade" <kwade(a)redhat.com>
> To: infra(a)ovirt.org
> Sent: Tuesday, August 14, 2012 5:24:09 PM
> Subject: Re: Puppet proposal
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/14/2012 03:25 AM, Eyal Edri wrote:
>> i have a deamon i've written already - attached.
> Do we have a git repo for the Infra team yet? I know we could have
> Puppet manifests in its own repo, but we have other version control
> needs. Maybe one repo?
i recommend one repo for puppet classes. ('puppet')
we can publish it to community also, so people can contribute puppet classes we well.
i still think we need a separate 'jenkins' repo for all jenkins code, for
personal exp using complex jenkins code in jobs.
but i won't object to have a single repo for starts with subdirectories (/jenkins
/puppet /foreman)
I personally think we need diff repo's for Puppet and Jenkins.
I know
foreman intergrates with Puppet so those might be able to share the same
repo but that is call we can make when we go to intergrate foreman in.
Thanks
Robert
E.
> - - Karsten
> - --
> Karsten 'quaid' Wade, Sr. Analyst - Community Growth
> http://TheOpenSourceWay.org .^\ http://community.redhat.com
> @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
--
Thanks
Robert Middleswarth
@rmiddle (twitter/Freenode IRC)
@RobertM (OFTC IRC)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iD8DBQFQKl+J2ZIOBq0ODEERArmdAKCH4ro2WnKzyFu+TX6g8zlIdn5xWQCgxfVF
> 5KbY33AL3uVuGOJqQLlUdSc=
> =2cy5
> -----END PGP SIGNATURE-----
>
_______________________________________________
> Infra mailing list
> Infra(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
8:36 a.m.
----- Original Message -----
From: "Robert Middleswarth"
<robert(a)middleswarth.net>
To: infra(a)ovirt.org
Sent: Monday, August 20, 2012 12:05:53 AM
Subject: Re: Puppet proposal
On 08/14/2012 11:41 AM, Eyal Edri wrote:
>
> ----- Original Message -----
>> From: "Karsten 'quaid' Wade" <kwade(a)redhat.com>
>> To: infra(a)ovirt.org
>> Sent: Tuesday, August 14, 2012 5:24:09 PM
>> Subject: Re: Puppet proposal
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 08/14/2012 03:25 AM, Eyal Edri wrote:
>>> i have a deamon i've written already - attached.
>> Do we have a git repo for the Infra team yet? I know we could have
>> Puppet manifests in its own repo, but we have other version
>> control
>> needs. Maybe one repo?
> i recommend one repo for puppet classes. ('puppet')
> we can publish it to community also, so people can contribute
> puppet classes we well.
>
> i still think we need a separate 'jenkins' repo for all jenkins
> code, for personal exp using complex jenkins code in jobs.
>
> but i won't object to have a single repo for starts with
> subdirectories (/jenkins /puppet /foreman)
I personally think we need diff repo's for Puppet and Jenkins. I
know
foreman intergrates with Puppet so those might be able to share the
same
repo but that is call we can make when we go to intergrate foreman
in.
i agree, foreman has the option to manage the puppet repo also, via various environment
iirc,
so its not a good idea to put jenkins code there as well.
also, if jobs will listen to changes in Jenkins code, and puppet code will be in the same
repo,
jobs will be triggered for a change that might not be relevant to jenkins (e.g new puppet
class).
Thanks
Robert
>
> E.
>> - - Karsten
>> - --
>> Karsten 'quaid' Wade, Sr. Analyst - Community Growth
>> http://TheOpenSourceWay.org .^\ http://community.redhat.com
>> @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.12 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iD8DBQFQKl+J2ZIOBq0ODEERArmdAKCH4ro2WnKzyFu+TX6g8zlIdn5xWQCgxfVF
>> 5KbY33AL3uVuGOJqQLlUdSc=
>> =2cy5
>> -----END PGP SIGNATURE-----
>>
_______________________________________________
>> Infra mailing list
>> Infra(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>
> _______________________________________________
> Infra mailing list
> Infra(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
--
Thanks
Robert Middleswarth
@rmiddle (twitter/Freenode IRC)
@RobertM (OFTC IRC)
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
4260
days inactive
4267
days old
10 comments
4 participants
participants (4)
-
Ewoud Kohl van Wijngaarden -
Eyal Edri -
Karsten 'quaid' Wade -
Robert Middleswarth