[debian-lan-devel] Installation report

Sat May 4 20:03:57 UTC 2013

Follow-up on the installation report and answer to Andi's remarks :)

It was quite a busy week, mainly due to the "performances" issues and a
stubborn printer.

> The only major one is network performances. This is not directly bound to
> > debian-lan, but it's architecture makes it highly network dependent.
> > With a poor-man's network (100mb), old cables, old computers, the overall
> > reactivity of the desktop is quickly impacted. There are high variation
> of
> > reactivity and the cause is not yet identified. I just can say that it's
> > not the server which is nearly idle.
> > Tomorrow, I will be able to check if it's better since the installation
> of
> > some non-free network firmwares. Some tcpdump might help locate the
> cause.
>

The non-free firmwares (e.g.: firmware-realtek) and those like
firmware-linux (firmware-linux-nonfree) can improve some performances
issues.

>
> This is interesting, and we should definitely find out the reason for such
> bad performance.  Can you give some more information about the setup,
> i.e. how many workstations, diskless machines you have running?  Are
> gateway and server on different machines or do you use the setup where
> the mainserver acts as gateway?
>

Thus,
Bad performances were due to .... tadaaaam.... the tremendous amount of
emails stored in users inboxes (some of them had around 20K mails) which
made icedove react sluggishly and glued the whole desktop environment in
the concerned setup.
The network needed a big cleanup and some new cables improved the
responsiveness even with a 100Mb switch.

The server is actually the gateway, there are 8 linux workstations and 4
winstations. I left the diskless one temporarily because the startup
blocked and I had no time to investigate (+ the issue with LOGUSER which I
will be able to solve with Andi's suggestion). I supposed it's related to
some drivers.

>
> > On the minor ones:
> > - when I create the LOGUSER for fai, I'm requested to input Kerberos
> > credential, which I don't have. Seems that local users need to be created
> > before debian-lan installation. Otherwise, these users need to be within
> > ldap. I searched a bit but didn't found the best solution to apply.
>
> Hm, indeed, creating a local user doesn't work as usual, just tested
> it myself here.  You can create the account ignoring the kerberos
> password and modify it later:
>
> Create a password hash with "mkpasswd", and then use
>
> usermod -p YnxZ6TRKNzBLs test
>
> to update /etc/shadow.  But I agree, this is not perfect.  I guess PAM
> is responsible for mixing in Kerberos ...
>

OK, Thanks for the tips.
I saw some info about the problem with pam. I will check that again in the
lab.
Do we have any task/bug tracking we can use to manage such issues or do we
use debian's bug tracking?

>
> > - one failure with a disk-less client (not yet investigated)
>
abandoned issue

>  > - one failure with a workstation where grub was not successfully
> installed
> > (not yet investigated)
>
suddenly worked

> > - some packages need to be added for French environment (this will be
> > included in a separate config file)
>
> Oh yes, please add a class like FRENCH or the like ...
>
This will follow as a FR-Belgian class.
+ this needs a modification of /etc/default/keyboard because we use
CapsLock a lot.
I had to remove
XKBOPTIONS="xorg ctrl:nocaps"

>
> > - shorewall needs a bunch of rules to make the whole thing work. This
> will
> > be posted too and included in a config file.
>
> Very good idea to include shorewall!
>

This will follow (two_interfaces setup + openvpn)

>
> > - Squid was bypassed. This might need a configuration change to support
> > TPROXY and work along with shorewall. Testing tomorrow.
>

No time to test TPROXY yet (required some more configuration). Though users
are blocked by the proxy.
Isn't this rule blocking ?
# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

>  > - installation of flashplugin-nonfree needs a bypass for the proxy. This
> > will be tested tomorrow following information from wiki.debian.org.
>
To do

>  > - printing issues related to the network printer. Might need
> lsb-printing
> > package to support the provided drivers.
>
Not DL related. Printer needs a firmware update before anything else.

>  > - adding samba machines, not yet ok. But disk and printer sharing is
> OK.
>
 > - need a read-only user into ldap for some authentication needs like
> > printer connection, authentication from windows (home edition) with
> > pgina,...
> > - added support for openvpn but this should be better integrated into
> ldap.
> > - added fail2ban, just in case. I'll latter improve the shorewall config.
> > - I added a dirvish config for backups upon insertion of an external
> > usb-hdd. If someone needs it, I will post.
>
> That sounds pretty interesting, if you don't mind, please post it or
> add it to the wiki.
>
> I will post it.

> > - baddly need the educlient/eduroaming packages. This is my next target
> for
> > the coming days.
>
> There was/is a discussion about the roaming workstations on the
> debian-edu list:
>            https://lists.debian.org/debian-edu/2013/04/msg00192.html
>
> Perhaps we can learn from them ...
>
> > And, for my own education. I didn't tested the password expiration yet.
> > What should happen when password is about to expire (provided the warning
> > is enabled in Gosa) and is the user able to change it form its
> workstation
> > or needs to connect onto Gosa?
>
> I fear that this does not work.  All login passwords used are kept in the
> Kerberos KDC, and the password in GOsa is only used to log into the
> GOsa web page.  If a password is changed there, Kerberos is
> synchronized by the gosa-sync script.  If you change a password with
> kpasswd, the LDAP password used by GOsa is not modified, i.e. you have
> to login into GOsa with the old one.  This is by far not perfect, but
> unfortunately that's the state of GOsa.
>
>               http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698544
>
> Some times I wonder if we coulnd't try a fork with a simple openldap with
phpldapadmin?
Just for the sake of simplicity.
I will try that when time will permit.

> > All in all, this was quite a success!
>
> Yes, I am pretty happy that things work for you, and you already added
> quite some interesting stuff which might be interesting to include
> "upstream".
>
> Many thanks for reporting and keep us up to date!
>

> Best regards,
>
>      Andi
>

Thanks for your interest Andi. Glad to help

Julien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-lan-devel/attachments/20130504/01340797/attachment-0001.html>