For Testers:
Feedback appreciated
Never used a Nethsever image before ?
Login: root
Password: Nethesis,1234
EDIT: It is not OK if you release something while having second thoughts, keeps you awake at night… Hence this RC2 with another logic to get the network up @.first-boot. If you have a RC1 running : nothing will change, it just how we start system-init… sorry for this.
I was able to:
SAMBA4/AD - joined via Win to Pro
OpenVPN - site2site tunnel
Firewall - working as expected
Fail2ban - verified ban on LAN
SOGo 5 - works with sending/recieving & SAMBA auth. backend
Email - Relay, DKIM, Spam Filter & AV
Reverse Proxy
Note I had to rootfs-expand to get access to all of my SD card space.
thank you for testing a feedback, very much appreciated 
Yes, that’s expected behavior. Will add this in to the (default) release message.
Would be nice to have an configuration hint on this… unfortunately have no clue how to accomplish this. 
Which RPI model did you use?
Hardware - Raspberry Pi 4 Model B Rev 1.4
CPU - ARMv7 Processor rev 3 (v7l) x 4Quite happy myself too…
Finally got NS booting and running from USB3-UAS attached SSD drive now:
# mount | grep sda
/dev/sda2 on / type ext4 (rw,noatime)
/dev/sda1 on /boot type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
And it starts to fly 
, well for a SBC…
... esmith::event[653]: Event: system-init SUCCESS
... systemd[1]: Started Initialize NethServer configuration.
... systemd[1]: Startup finished in 3.158s (kernel) + 1min 41.709s (userspace) = 1min 44.868s.
Going to release final soon…
This in my opionion is a hot and upcoming semi beta project, could we get NethForge enabled by default?
Agree! To do this properly nethserver-nethforge-release needs to be added to the nethserver-iso group in the repositories. Being Christmas holiday season this may take a while…
POLING:
If I’m going to poke around in the comps (group-file) anyways i’d like the opinion from the community about following the x86_64 lead by making the traditional server-gui (httpd-admin) on port 980 optional…
0 voters
The (generic) Uboot image 7.8.2009 RC2 for arm 32 bit is also released (same release tab)
cc/@xcod (tested on OrangePI PC)
Vote stands +3 from 9 to make the traditional server-gui (httpd-admin) on port 980 optional.
That’s how it’s going to be…(Even without a transition of power)
type for a little bit relfection…
The final images are “burning” on my desk to be released…However I hoped CentOS would have released a kernel update for the RPI by now. The current centos-rpi kernel OOPS on zram-swap on the 8G ram model. Hence the nethserver raspberry RC images run a home build kernel with two upstream patches, installed form a local repository.
Versioned this kernel with defensively with just a extra .1 for the (build)release. Meaning when CentOS releases a kernel update this will always be an update…
now what to do:
Hi
I’d release now, depending if you have a well accessible repo or not options 1 or 2…
My 2 cents
Andy
It seems the obvious choice if it is already on sight. Is there any ETA from upstream?
Pinged the arm-dev mail-list just now:
https://lists.centos.org/pipermail/arm-dev/2021-January/007929.html
The Ping on the CentOS arm-dev list helped, final images for arm32 bit are released.
How do we update if the previous version is already installed? Will the updates in Software Centre take care of this?
Many thanks
Andrew
It was for most waiting for a new kernel release by CentOS as the RC2 run a kernel patched by me. This kernel (ATTOW kernel 5.4.88) should be pulled in by a update now.
If your use case requires DHCP on the Ethernet port of the RPi4 instead of a fixed IP you may want to:
cat > /etc/systemd/system/network.service.d/wait-for-eth0.conf<< EOF
[Unit]
After=sys-subsystem-net-devices-eth0.device
Requires=sys-subsystem-net-devices-eth0.device
EOF
The above is actually re-added because your report of a issue regarding fetching an IP at first-boot.
Downloaded and deployed today. I’ll report back with any notable details but so far pretty straight forward as expected.
EDIT - @mark_nl first note on my RP4 - after first intall my device pulled an IP address and was accessible via cockpit but did not have a valid gateway. After expanding the root partition I then reset the Green LAN to DHCP and the gateway was established.
The strange thing is, it just does not happen to me… 
Not on my local network where a NS is the DHCP server ( for testing removed the lease before booting the PI several times)
It does not happen to me if it is plugged into the router of my ISP modem, which in the network topology is before the above mentioned NS and has a DHCP server enabled.
It always brings up network / dns here. 
Only little glitch I can report is: if connected to the local network it only picks-up the IP of internal (NS) DNS server… Still can resolve external hostnames through that.
