Setting up a PDC on armhfp

The nerthserver-dc nodule is not available for armhfp. Reason is it is a special module which runs a vanilla samba instance in a (systemd) nspawn container.
I got it running in the past but needed to thinker a lot due to installation/configuration timeouts and reckoned the installation to be to unpredictable.

This was about 2 years ago and things may have changed so lets try it again. :grinning:
Would not get to high hopes though…

1 Like

ClearOS has always supported roaming profiles as a Samba 3 PDC. I will just have to figure out what they/I did and get it working with the LDAP provider for now.

Also this probably means I need less memory and I might be able to use one of my Cubieboard2 with 1GB memory instead of the Cubietruck with 2GB. For this purpose, this is their only difference; both have the A20 chip.

First thing to tackle is compile a vanilla (ns-)samba for armhfp.

ns-samba did compile but have trouble with packaging it.

Processing files: ns-samba-4.7.10-1.ns7.armv7hl
error: File not found: /builddir/build/BUILDROOT/ns-samba-4.7.10-1.ns7.arm/usr/share/man/man5/pam_winbind.conf.5

line in generated file-list (ns-samba-4.7.10.filelist)

in reality:

<mock-chroot> sh-4.2# ls /builddir/build/BUILDROOT/ns-samba-4.7.10-1.ns7.arm/usr/share/man/man5/pam_winbind.conf.5*

Note gz : pam_winbind.conf.5.gz

@davidep do you have suggestions / directions / ideas what is happening?

My bad: used the wrong mock cfg.

1 Like

I hit this kind of error on slow machines with a poor random numbers source. The certificate generation task was freezing the whole process until it timed out.


First see my howto on better random number entropy, but I suspect this is not the problem here.

Perhaps can we change from RSA to at least ECDSA? Generation of equiv straight is faster. Plus use is faster. And EDDSA is finally in openSSL 1.1.1

See my Internet Drafts on using the command line openSSL to build PKIs with these algorithms so you can test out using them. I did this because at the IETF hackathon, people were saying they could not test with certs because it was too hard to go to a commercial PKI to get what they needed just for testing…

1 Like

Lovely elliptic curve: we had a close encounter with it last spring! But here (with NSDC) the certificate is (still) generated by Samba startup scripts.

We have plans to integrate it with the host system certificate though: SSL certificates for Samba AD (NSDC host). It would remove the task of generating it for NSDC.

meanwhile (on second run) nethserver-dc did install on a RPI3+ with a really decent SD card.

One reoccurring error during install/configuration/provisioning (line 1501):

lets see if it works and how it behaves :grinning:

A lot of my colleagues in the IETF do not agree. I know some of the history behind ECDSA. Very interesting indeed! On a sabbatical to Canada? Test values that become production?

Some feel that the timing attacks can be managed and that EDDSA was rushed. I don’t like how they used SHA512 instead of SHAKE128 or SHAKE256 if they really had to. This impacts really small systems.

But you can see that openSSH already supports both ECDSA and EDDSA.

I might be able to lend a hand on the cert stuff, though I am rusty on some aspects.

1 Like

You can ignore it. It’s not a real issue:

We tried to set up ECC certificates support, but we’re not experts on the field: any help is welcome!

The nethserver-dc package (and group) is in the arm 7.5.1804 repository

NOTE: it’s development and I have it installed just once, good chance it will fail and wreck your arm installation

To see if installation is going well i recommend to follow the progress on a (ssh)terminal with journalctl -f

As it stands now the most critical part is likely the time the installer waits for the nscd container to boot and serve SRV records. On x86_64 it waits for max 5 minutes and it’s prolonged to 10 min for armhfp. (on my RPI3+ it took 1min 40sec.)

Installation and preparation is as usual:

Do not forget to grow your rootfs before installing the local AD, the nsdc container of aprox 580MB does not fit on the rootfs partition of the currently shipped image. (see README in /root)


I started the install of the DC. It wanted me to specify a different address than what the system was running on. So I supplied (currently on .14). Seems it is going to use a /24 subnet which will work for starters.

So it gets 62% done with the message adjust-services and hangs.

the last few messages from journalctl -f is:

Oct 09 18:47:10 systemd[1]: Started DNS caching server…
Oct 09 18:47:10 systemd[1]: Starting DNS caching server…
Oct 09 18:47:10 dnsmasq[10475]: started, version 2.76 cachesize 4000
Oct 09 18:47:10 dnsmasq[10475]: compile time options: IPv6 GNU-getopt DBus no-i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify
Oct 09 18:47:10 dnsmasq-tftp[10475]: TFTP root is /var/lib/tftpboot
Oct 09 18:47:10 dnsmasq[10475]: using nameserver
Oct 09 18:47:10 dnsmasq[10475]: read /etc/hosts - 2 addresses
Oct 09 18:47:10 esmith::event[8963]: Action: /etc/e-smith/events/actions/adjust-services SUCCESS [3.58274]

So I check IP:

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
link/ether 02:c1:08:81:e2:d7 brd ff:ff:ff:ff:ff:ff
inet6 fe80::c1:8ff:fe81:e2d7/64 scope link
valid_lft forever preferred_lft forever

hmm, no IP address. So

cat /etc/sysconfig/network-scripts/ifcfg-eth0


no wonder no IP address.

Since this is with the arm build, do you want to move this trouble shooting over to the arm testing thread(s)?

Looks like I was a bit premature on giving up and going away…

ifcfg-eth0 still the same, but I see:

cat /etc/sysconfig/network-scripts/ifcfg-br0

And the install ended with errors:

 Task completed with errors

S96nethserver-dc-createldapservice #15 (exit status 256)
S95nethserver-dc-waitstart #23 (exit status 256)
S96nethserver-dc-createldapservice #24 (exit status 256)
S96nethserver-dc-join #25 (exit status 256)
S97nethserver-dc-password-policy #26 (exit status 256)
S98nethserver-dc-createadmins #28 (exit status 256)
Adjust service sssd #157 (exit status 1)
Template /var/lib/machines/nsdc/etc/ntp.conf #131 (exit status 1)
    expansion of /var/lib/machines/nsdc/etc/ntp.conf failed
Template /var/lib/machines/nsdc/etc/hosts #132 (exit status 1)
    expansion of /var/lib/machines/nsdc/etc/hosts failed
Template /var/lib/machines/nsdc/etc/resolv.conf #133 (exit status 1)
    expansion of /var/lib/machines/nsdc/etc/resolv.conf failed
Template /var/lib/machines/nsdc/etc/hostname #134 (exit status 1)
    expansion of /var/lib/machines/nsdc/etc/hostname failed
Template /var/lib/machines/nsdc/etc/systemd/system/nsdc-run@.service #135 (exit status 1)
    expansion of /var/lib/machines/nsdc/etc/systemd/system/nsdc-run@.service failed
Template /var/lib/machines/nsdc/etc/systemd/system/samba-provision.service #136 (exit status 1)
    expansion of /var/lib/machines/nsdc/etc/systemd/system/samba-provision.service failed
Template /var/lib/machines/nsdc/etc/systemd/system/nsdc-run.socket #137 (exit status 1)
    expansion of /var/lib/machines/nsdc/etc/systemd/system/nsdc-run.socket failed
Template /var/lib/machines/nsdc/etc/systemd/network/ #138 (exit status 1)
    expansion of /var/lib/machines/nsdc/etc/systemd/network/ failed
Template /var/lib/machines/nsdc/etc/samba/smb.conf.include #139 (exit status 1)
    expansion of /var/lib/machines/nsdc/etc/samba/smb.conf.include failed
Template /var/lib/machines/nsdc/srv/smb.ns6upgrade.conf #140 (exit status 1)
    expansion of /var/lib/machines/nsdc/srv/smb.ns6upgrade.conf failed
Template /var/lib/machines/nsdc/srv/ #141 (exit status 1)
    expansion of /var/lib/machines/nsdc/srv/ failed

for DNS name I used:

for netbios name: HOMEBASE

and as I previously said the DC IP addr is

It is not too much of an issue to rebuild the image from scratch and start again tomorrow…

BTW, as I think of it, I would like the DNS name to be home.htt; something that is not usable at all externally. This is what I did with my ClearOS setup; I hope it will work here.

I read

I don’t see this as a concern for my small home network. I am assuming that the server itself can keep its name in the internal view.

I took the liberty to change the subject, if you wish you can change back. :grinning:

Looks like the installation of (the packages of) the container failed.

Key to indicate success of this part of the installation is line 1266 in my log:

Oct 09 16:54:44 rpi3p.havak.lan esmith::event[1567]: Complete!
Oct 09 16:54:44 rpi3p.havak.lan esmith::event[1567]: Created symlink from /etc/systemd/system/ to /usr/lib/systemd/system/
Oct 09 16:54:44 rpi3p.havak.lan systemd[1]: Reloading.

Sorry to ask:
Did you grow your rootfs before installing the AD. I think i should have mentioned it won’t fit on the partition of the currently shipped image. see README in /root to grow the rootfs.

1 Like

This is good.

#df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        953M     0  953M   0% /dev
tmpfs          1007M     0 1007M   0% /dev/shm
tmpfs          1007M   25M  982M   3% /run
tmpfs          1007M     0 1007M   0% /sys/fs/cgroup
/dev/sda3       155G  1.2G  152G   1% /
/dev/sda1       642M  164M  459M  27% /boot
tmpfs           202M     0  202M   0% /run/user/0

I think I made it big enough for a lot of user data…

Now in order, I first installed file server (which auto installed firewall) THEN I ‘went back’ to install user/group provider.

Perhaps that has an impact?

yes 152G should do it… (understatement of year :wink:)

Sorry I do not know. It may sould a bit strange: Having the nethserver-dc package dismissed for arm in the past, I am not very familiar with it.

Maybe others can chip in how to debug this.

Just can share my work flow:

  1. configure network: set green interface to fixed IP (and make a record for it in the my local DNS server)
  2. update
  3. grow rootfs partition
  4. reboot
  5. install account provider
  6. then install other modules, usually one at a time

to be accurate: between 1 and 2 provide a selfsigned-certificate trusted my local environment. This because firefox goes crazy if you have multiple exceptions for the same ip/hostname (which happens if you reinstall the same SBC over and over again)

A habit of me while testing/debugging is to reboot before installing the “test subject” and write hole journalctl of the event to a file. ( journalctl > my_event.log ).
There may be more sophisticated methods, it works for me…

BTW a log of the hole event should be logged in /var/log/messages which can also be viewed in the web-ui at Administration > Log viewer > /var/log/messages


I started from scratch with the base image. I expanded the rootfs partition while the drive was still connected to my notebook using gparted. I am lazy that way. Plus I like to look at what whatever arm image is doing partition-wise.

  1. changed the root password
  2. set the timezone to America/Detroit using timedatectl
  3. Install zram

Connected to port 980 and went through the setup.

This time it did not ask me to change the root password, as I changed it from the serial console earlier.

It prompted me for the timezone, offering that current was DETROIT; I wonder what would have happened if the tz file has a city name in two regions? :slight_smile: We had a discussion about setting time zones in both the Fedora user and Xfce lists. Gnome has moved past using the tz file, giving much better geo choices…

Then I was on the interface dialog and it recommended I change from a DHCP address. So this time I did. This is the important difference than before, where I kept the system on the dhcp address.

Note that when I changed the IP address, I lost my connection. I have been on devices where when I changed address, I was issued a redirect to the new address before the interface was bounced. Not the case here. You should have a warning here about reconnecting to the new address.

I then went to the install AD dialog. Set up domain dns as home.htt and Netbios as HOMEBASE and IP as on the same network as the static. This time the install worked.

So please update the install instructions page:

to say the importance of changing to a static address if you expect the provider installation to work.

Oh, and I see on the Dashboard, that you are now picking up that I am running on a Cubietruck.


Thank you for your persistence in testing and feedback!

Yes prompts whatever is set, during image build it is set to UTC.
I did thinker to try to set it at first boot using one of the services out there:
curl && echo " is my timezone"

Allways good to have new eyes/thoughts and experiences! But is the yellow warning banner in the web-ui (something like, forgot the actual text) “green interface on dhcp” not good enough?

It does not say that some software installation will fail badly. In fact you could go the extra mile and have a flag for some software installs not to install if IP add is DHCP. I can think of at least one where it shouldn’t matter: SQL. But you can even go the distance that no software can be installed until static is set.

Thing is I can think of installations where DHCP is perfectly valid for the Green network.

You will get people like me that will try and push things because we always have and were there when DHCP was ‘invented’!

Now speaking about pushing things. I set up my AD DNS as home.htt, because I like my AD DNS to be really private, and Microsoft says I can.

Well, I can’t create and groups or users for this DNS. They are all for the server’s domain of I spent some time looking at what things I can configure, and I don’t see any way to work with groups or users for the AD domain. Perhaps it is not necessary? This will all be taken care of when a machine joins the domain?

I read through
a number of times and other than a tip not to do this, it does not come out and say that things won’t work?

As said, I do know the nethserver-dc package very well. Encountered it doing some work on SOGo which binds to AD/LDAP.

Note you are referring to M$ documentation from 2009 applicable to M$server 2000-2003. AFAIK this are NT4.0 style PDC’s and we are in the era of the new style Active Directory.

Being Dutch -who are known for direct communication- I can agree documentation can be more compelling on some points. On the other hand: why dictate what you should do, advice you to choose a direction has it’s charm. And note with the e-smith configuration layer you can mold nethserver exactly to your like.