[SAC] [[support.osuosl.org #11303] OSGeos New Servers]

Anyone have any thoughts on the questions/error noted below.
1. LDAP boot error
2. How much swap (I'm inclined to lower the amount since we have lots of
ram)

I'll need answer in the next 16ish hours to ensure the new VMs are
created tomorrow.

Thanks,
Alex

-------- Original Message --------
Subject: [support.osuosl.org #11303] OSGeos New Servers
Date: Mon, 29 Mar 2010 23:52:31 +0000

On Mon Mar 29 16:40:18 2010, tech@wildintellect.com wrote:

Looks like our team has finished configuring the Base image.(It would
be great if we could access it later at base.osgeo.osuosl.org to make
updates if we need to).

So now we're ready for 3 Vms:
wiki.osgeo.org(aka Wiki)
host osgeo3
Debian Stable +Backports
4 GB RAM
16 GB HD
DRBD - No
2 core

Secure
secure.osgeo.org(aka Secure)
host osgeo3
Debian Stable +Backports
4 GB RAM
10 GB HD
DRBD - Yes
2 core

Backup
backup.osgeo.org(aka Backup)
host osgeo4
Debian Stable +Backports
8 GB RAM
500 GB HD <- is this a good idea or is there a better way to do it
like a mounted directory from the host?
DRBD - No
2 core

Looks like there's an annoying bug/issue with debian [1] [2], ldap, and
udev
when booting. But see if you can log into base.osgeo.osuosl.org right
now.

[1] http://lists.debian.org/debian-boot/2006/09/msg00223.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375077

This is what it prints out when booting:

INIT: version 2.86 booting
Starting the hotplug events dispatcher: udevdudevd[849]: nss_ldap: could
not connect to any LDAP server as (null) - Can't contact LDAP server
udevd[849]: nss_ldap: failed to bind to LDAP server
ldaps://ldap.osgeo.org/: Can't contact LDAP server
udevd[849]: nss_ldap: could not search LDAP server - Server is
unavailable
udevd[849]: lookup_group: error resolving group 'scanner': Illegal seek

To get around having it wait, I added the following to
/etc/libnss-ldap.conf:

  bind_policy soft

We still see the errors, but it at least boots fast. If you're ok with
me adding that option I'll keep it in the image.

I had another question regarding swap on the VMs. First, do you want
swap, and if so how much? Currently my deployment script creates a swap
volume that is equal to the amount of RAM set on the machine, however
that doesn't seem sane to do on VMs with a lot of ram like yours. I need
to adjust my deployment scripts to make swap more configurable, but it
shouldn't take me very long to do that.

I'm waiting on these two items before I move forward on creating the
VMs.

Thanks-

--
Lance Albertson
Systems Administrator / Architect
Open Source Lab

On Mar 29, 2010, at 7:22 PM, Alex Mandel wrote:

Anyone have any thoughts on the questions/error noted below.
1. LDAP boot error

I remember reading something in the debian LDAP client docs about adding the ldap server's ip address to /etc/hosts to avoid recursive lookups under some situations. Of course, if when we want to move the LDAP server inside of OSL, this means reimaging :(. Maybe this isn't the problem.

Additionally, connections outside of the class c that we designated are not going to work, do you happen to know if they were using an IP address inside of 140.211.15.0/24?

2. How much swap (I'm inclined to lower the amount since we have lots of
ram)

I'll need answer in the next 16ish hours to ensure the new VMs are
created tomorrow.

I'll defer to whatever you deem reasonable.

Howard Butler wrote:

On Mar 29, 2010, at 7:22 PM, Alex Mandel wrote:

Anyone have any thoughts on the questions/error noted below.
1. LDAP boot error

I remember reading something in the debian LDAP client docs about adding the ldap server's ip address to /etc/hosts to avoid recursive lookups under some situations. Of course, if when we want to move the LDAP server inside of OSL, this means reimaging :(. Maybe this isn't the problem.

Additionally, connections outside of the class c that we designated are not going to work, do you happen to know if they were using an IP address inside of 140.211.15.0/24?

I believe there are plans to move the LDAP server to Secure which is
part of the 1st round of VMs. This seems like something easy to fix
after the fact on existing images and update in the base image. The base
image will be available at base.osgeo.osuosl.org whenever we turn it
on/off once we have access to the host.

Yes I believe all of our VMs will be in that ip address range.

Thanks,
Alex