[Viper-users] Getting started with viper

[Timm Essigke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Davor,

Davor Ocelic wrote:
> Just one hint here: the template doesn't change, so if you have it
> defined in the global ou=defaults, you don't need to re-define it on a
> site- or host-level. They'll just always fallback to global default and
> work as expected.
Great! Because the examples were defining a new template for every
host, I thought it is required. I found it a bit redundant, but didn't
try without separate templates. But, yes, it works!
>
> You did it correct, and it should work.
> I just tested it here and it does work in my setup.
>
Hmm... I must admit, that I can't reproduce it myself today. The
caches are off. Maybe I made a silly mistake yesterday?!
> Yes, you are right about this. You can override values on per-site or
> per-host level, but there's currently no support for grouping.
>
> So the solution I will implement as soon as I get a chance (tomorrow
> or so) is this:
>
I am looking forward to your solution!
> Point 2) will allow us to keep all this "rewrite/fallbacks magic" in
> separate suffixes intended only for access by specialized clients,
> which is much better than adding it all to ou=clients tree and potentially
> confusing people who might connect with a normal, GUI LDAP client.
Yes, also one of my first steps was to install phpldapadmin to have a
look at the tree instead of reading the ldif files. Didn't work very
well, so I would appreciate a change.
>
> It will probably also allow us to get rid of the ugly o=CLIENT,ou=clients
> naming scheme, and you'll be able to name your clients dc=example,dc=com
> like it is normal and somewhat of a standard.
That would be very nice, too. Thought already how to may the viper
tree into my usual LDAP tree. For example, I am planning to use bind
and Kerberos with LDAP backend.
>> Another obvious extension would be to PXE-boot the Debian ISO.
>
> Yes, this is most certainly planned, I just didn't have the time to
> check what is necessary to support this.
It is also not top priority for me. Maybe I will have a look into it
at some point. Obviously here the grouping will be handy, too, e.g.
i386 vs. amd64, debian vs. ubuntu, different OS versions, etc.

Going a bit beyond the current scope of viper: Since puppet is well
suited for recipes fitting for different Linux/Unix distributions, I
think it could be a great extension to support also other installers.
I have no experience with RH kickstart or SUSE autoyast, but having a
quick look, it seems that one could have some general definition
within viper which is mapped to the autoinstall file syntax of the
chosen distribution. A plugable API would be great, that  it can be
extended further without diving deep into viper code. Guess there are
similar autoinstall files in the BSD and Solaris world.
The information, which is needed by the installer is always almost the
same. I think it is doable, if one does not support all installer
options, but only those required for a minimal installation. The rest
can (and should) be done within puppet.

It is not a feature I currently need, but could be something hosting
providers are looking for. Sometimes it would be nice to try some RPM
based software or the support of a company requires that some (most
likely hardware) problem has to verified with RHEL or SLES.
>> Since viper installations mostly make sense in larger environments, I
>> think the default WEBrick server should be replaced by mongrel or
>> passenger already in the default installation. I am going to do this
>> in the next days in my installation.
>
> Please do. Contributions in this area and other things you do that
> might be of general usefulness (i.e. your lvm_vm partitioning recipe)
> are welcome.
I will post it extra.
>
> Also, I've talked with some Puppet folks who run larger sites (100+
> clients) the other day, and they said they gave up on trying to get
> Puppetmaster server to scale that much (compiling host configurations
> takes a long time).
>
> They just implemented a mechanism where each client grabs its own
> configuration, and compiles and executes it itself.
>
> So that may be another option to consider, depending on your setup.
I haven't read about this option on the puppet wiki pages. Maybe I
missed it or it is under development still.
I am also just starting with puppet, so I haven't experienced
performance problems yet. I just know about it because it is discussed
a lot. Jeroen van Meeuwen (www.puppetmanaged.org) at the LinuxTag said
he is running some thousand  hosts with puppet, but he has a hierarchy
of puppet masters managing other puppet masters.
>> What is the reason for automatically signing puppet certificates?
>
> It was the easiest to do in my test setup. If you can come up with a
> "do this, do that" recipe for replacing it with a better approach,
> we can change that.
I will also have a look into that. Maybe it is just my paranoia... :-)
>>         sed 's/\s\+$//' $p | ldapadd  -x -D cn=admin,ou=clients \
>>                 -w nevairbe   || exit 1
>>
>> Can you explain this a bit more? The spaces are necessary for proper
>> functioning, i.e. if you remove the spaces like you show with sed,
>> it would remove spaces from all places, and if nothing else, it'd
>> break ldif continuation lines which begin with space, and partman
>> partitioning schemes which also have strict spacing rules.
The sed expression says: remove 1..n spaces before a newline ($). It
does not touch other spaces, thus it does not cause the problems you
describe. In one of my first attempts I had a space after the  cn of a
host ("cn: viper1 "), which let to quoted hostnames including the
whitespace (looking at it with node_data). I think the dhcpOption
host-name was not processed correctly. The system installes with the
default hostname "debian".
>> Another bug seems to be that hostnames with underscore (e.g.
>> viper_test) do not work. Might be a d-i problem, I don't know.
>> However, e.g. viper-test works.
>
> I didn't do anything special for this behavior, but it behaves like
> the specification says:
>
> "RFCs mandate that a hostname's labels may contain only the ASCII
> letters 'a' through 'z' (case-insensitive), the digits '0' through '9',
> and the hyphen. Hostname labels cannot begin or end with a hyphen. No
> other symbols, punctuation characters, or blank spaces are permitted."
>
Sorry, didn't know that I disregard a RFC. :-)
I am used to have hostnames with underscores and didn't experience
problems so far. Can't remember why I started using underscores. One
"problem" I had in some of my LVM scripts was that
/dev/viper-test/root is /dev/mapper/viper--test-root. Nothing one
can't handle, but with underscore the hyphen is clearly a designator
for a LV name. I don't mind if you want to stick to the RFC strictly.
>> What is the right way to switch between different Debian/Ubuntu
>> versions? I found "choose-mirror-bin" in my d-i preseed file, but
>> there is no template for it yet. Is there an alternative way?
>
> Currently, no way. Soon it will be possible with the groups mechanism
> that I'll add.
>
> And I already have a .ldif file with ubuntu-specific keys ready, so
> it'll work out of the box as soon as I commit it.
>
Having different releases is definitively something I would like to
have. I think about having testing on some of my VMs and workstations
to have a rolling release system instead of the "fear" of a big
release upgrade. Debian stable tends also to be pretty old.... Should
be possible with puppet to dist-upgrade the hosts regularly. I am
thinking about having two groups of machines which are upgraded in an
alternating way. If some update breaks something, I can either fix it
or roll back to the installation of the other hosts. Or I will have a
test network (of virtual machines) which is upgraded, tested and than
updates are released to the production network.

Anyhow, there are many things which could be done with viper & puppet
in future!

All the best,

Timm


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrI450ACgkQ9cEzJ2deIqKMRgCfYoeJ5RdyFfuTEsCswjE7ZWXZ
Sz0AoJlBa0RkAgcSQg6I4wSntrl5kdMm
=WBM5
-----END PGP SIGNATURE-----