[Viper-users] Getting started with viper

[Davor Ocelic]

On Sat, 03 Oct 2009 20:53:58 +0200
Timm Essigke <Timm.Essigke at uni-bayreuth.de> wrote:

Hey,

> 
> I can change the partitioning scheme, but not on a per-host basis with
> 
> dn:
> cn=partman-auto/expert_recipe,cn=viper1,ou=templates,o=bisb.uni-bayreuth.de,ou=clients
> objectClass: top
> objectClass: debConfDbEntry
> cn: partman-auto/expert_recipe
> description: for internal use; can be preseeded
> extendedDescription: Expert recipe content
> type: string

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.

> dn:
> cn=partman-auto/expert_recipe,cn=viper1,ou=hosts,o=bisb.uni-bayreuth.de,ou=clients
> objectClass: top
> objectClass: debConfDbEntry
> cn: partman-auto/expert_recipe
> flags: preseed
> owners: partman-auto
> template: partman-auto/expert_recipe
> value: exp $ cn=lvm_vm,ou=partitioning,ou=Defaults data
> 
> Is this a bug or do I misunderstand the data  structure?

You did it correct, and it should work.
I just tested it here and it does work in my setup.

See if you have "cacheRead" or "overlayConfig" cache defined
in slapd.conf. You should disable them if they're enabled,
and restart slapd.
(I've spotted a bug somewhere in the cache code which caches
the value for more than it should.)

If it's not a cache issue, report back and I'll give you info
on how you can quickly debug the issue.

> Maybe I missed something, but I do not see a way to group
> configuration options for preseeding, i.e. all my VMs have a disk
> /dev/vda and should have a common partitioning pattern, some of my
> workstations have a disk /dev/sda and should use another partitioning
> pattern than the VMs, there are workstations with PATA disks /dev/hda
> which should use the same partitoning pattern as the SATA disk
> workstations, compute nodes should again have a different partitioning
> pattern etc. I think about something like the concept of puppet
> classes/modules of a node.
>
> Certainly, if the above problem is solved, I could make some template
> ldif file, search&replace the hostname and adjust IP and MAC (or do
> this within the puppet configuration of the viper server or with some
> other script). Anyway, I think direct grouping of hosts apart from at
> client level (i.e. within the same domain) would be useful.

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.

This is probably the most important feature to add at this point, for
more than one reason. (For example, it would also solve the problem
of multiple OSs (debian/ubuntu) by just placing them in different
groups and automatically looking up different sets of preseed
keys etc.).

I think that the current implementation of default values (configured
via searchFallback directive in slapd.conf) is too limited, because
it can only redirect entry lookups based on their DN, not on any of
their attributes. And the DN alone is useless in determining group
membership.

So the solution I will implement as soon as I get a chance (tomorrow
or so) is this:

1) Extend searchFallback functionality so that it can redirect based
 on entry attributes, i.e. you will be able to specify that a host
 belongs to groups one,two,three, and redirect lookup there, in order
 as specified.

2) Add new suffix ou=debconf, intended for access by preseed script
 and debconf clients.

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.

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.

> Another obvious extension would be to PXE-boot the Debian ISO. Do you
> plan to do this? Probably only DHCP options have to be adjusted to
> respond to netboot requests and a TFTP server has to be enabled.

Yes, this is most certainly planned, I just didn't have the time to
check what is necessary to support this.

> 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.

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.

> What is the reason for automatically signing puppet certificates? I am
> worried because of the security implications. So far I haven't tried
> what happens when I turn it off again.

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.

> BTW, ldapadd in /etc/ldap/viper/ldifs/add includes whitespace into
> LDAP which might lead to failures. Here is a simple fix with sed:
> 
> for p in ${1:-*.ldif}; do
>        echo $p
>         sed 's/\s\+$//' $p | ldapadd  -x -D cn=admin,ou=clients \
>                 -w nevairbe   || exit 1
> done

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.

> Because you see I still have the default passwords - it would be nice
> if the installation script could set the passwords according to some
> arguments or the scripts could be changed to parse a central config
> file with passwords.

Adding to TODO.

> 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."

> 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.

> Sorry for niggling on so many things. I have to emphasize again, that
> I like viper a lot. It just seems to me very young and haven't had
> much testing by users yet. :-)
>
> Thanks a lot for the great tool!

Great feedback, thanks.

-doc

> 
> Timm
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkrHncYACgkQ9cEzJ2deIqLm6gCfayNUK8iNFtmUtTuFLuyptdp4
> wfYAnR751f/ykv4bJnAZBstulOXaGED1
> =spdQ
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Viper-users mailing list
> Viper-users at lists.hcoop.net
> https://lists.hcoop.net/listinfo/viper-users