Re: Client time/date synchronisation
Hi Roman, [ roman.me...@gismap.ch, 2021-04-22 ] > This morning I decided to switch back to the original amd64 image and > testing with a newer client device I just got. > > The good news is that everything seems to work just fine. The device > is booting nicely as thin client. LDAP settings are added as expected > to /run/ltsp/ltsp_config_env and there's a new entry "server ntp" at > the end of /etc/ntp.conf. Good. > These things are not happening when I boot using the i386 image. > More ideas why this is happening? Might be due to the 64-bit/32-bit mix. I don't have a test environment to check it, though. As another option to get the Toughbooks working, you could install the combined server using the 32-bit BD ISO image, see the status page: https://wiki.debian.org/DebianEdu/Status/Buster#Download_using_http The LTSP chroot will be 32-bit (i386) by default in this case (so no $arch mix) and things should work also for 64-bit clients. Wolfgang signature.asc Description: PGP signature
Re: Client time/date synchronisation
Hi Wolfgang, I have new findings which may help to narrow things down hopefully. This morning I decided to switch back to the original amd64 image and testing with a newer client device I just got. The good news is that everything seems to work just fine. The device is booting nicely as thin client. LDAP settings are added as expected to /run/ltsp/ltsp_config_env and there's a new entry "server ntp" at the end of /etc/ntp.conf. These things are not happending when I boot using the i386 image. More ideas why this is happening? Kind regards, Roman > On 04/21/2021 4:32 PM Wolfgang Schweer wrote: > > > [ roman.me...@gismap.ch, 2021-04-21 ] > > I have added the suggested line to LDAP. It looks like this now: > > > > 121 cn=ltspConfigDefault,ou=ltsp,dc=skole,dc=skolelinux,dc=no > > objectClass: ltspClientConfig > > cn: ltspConfigDefault > > ltspConfig: KEEP_SYSTEM_SERVICES=lightdm > > ltspConfig: LTSP_FATCLIENT="False" > > ltspConfig: TIMESERVER=ntp > > > > After this, my client still boots as "diskless workstation" and the > > content of /run/ltsp/ltsp_config_env shows LTSP_FATCLIENT="True" > > instead of "False". > > That's weird, but I expected something like this because ntp.conf was > left unchanged according to your report. > > There should be LTSP_FATCLIENT="True" in ltsp_config_env before the > three mentioned settings, but LTSP_FATCLIENT="False" at the end > (overriding the first occurence). > > > Are changes to LDAP validated on-the-fly upon save or do I need to add > > another step like commit, rebuilding the image, etc.? > > No additional step needed. During LTSP client boot, some scripts are > executed to configure the client (overlay filesystem). The scripts are > located in the /usr/share/ltsp/init-ltsp.d/ directory inside the > SquashFS image resp. in /opt/ltsp/i386/usr/share/ltsp/init-ltsp.d/ > > Please check those places. > > Wolfgang
Bug#987327: Bug#986984: Bug#987327: autopkgtests for debian-edu-doc binary packages
Hi, Just to be sure, I love autopkgtest, but I have a few comments. On 21-04-2021 23:09, Wolfgang Schweer wrote: > [ Holger Levsen, 2021-04-21 ] >> we should add autopkgtests to debian-edu-doc to ensure each document >> has been built for the three formats pdf, epub and html. To be honest, I'm wondering if what you're envisioning here shouldn't be (also) done as BUILD test. I mean, if some documentation goes missing, it's good to fail the build and prevent a broken package in unstable. Very often, build tests are used as autopkgtests too, but checking for existence of files in the binary package only needs to be done once, not with every dependency change. > In some cases, verifying the format would have revealed the cause for > missing files/internal issues, i.e would have allowed one to locate the > broken XML syntax (most cases) more easily. > > src:desktop-base has an autopkgtest to validate XML files, xmllint from > libxml2-utils is used. Maybe xmllint could also be used to check HTML > files. That's also a great test during build. Realize however that if you do this during autopkgtest there's a risk that you'll *block* a new version of the checker because of a bug in *your* package. Obviously that has to be weighted against catching bugs in the checker, so it goes both ways, but *most* of the autopkgtest failures that I've seen that involved checkers, the checkers actually got better and found an issue in the reverse dependency. It's obviously a choice you'll have to make and there's much value in having an autopkgtest, but I just wanted to point out it's not a free lunch. Paul OpenPGP_signature Description: OpenPGP digital signature
