No…I didn’t made a screenshot, but I can affirm that the first NIC is configured as GREEN, and the second NIC was without attributed rules…
When connecting for the first time, on the first green NIC, I had the message than there’s a NIC without rule.
And when I gone to configure this second NIC, to attribute a green rule too… I had the little windows "configuring shorewall "… until loosing the connection:
Apparently, Nethserver, don’t like configuring 2 GREEN NICs, with 2 different subnet and without RED.
I was stuck, three time in this exact ste I had to doing three time the installation until thinking a way to dribble this point !!!
What I do to bypass this step:
I made the same install, but the first time I go to configure this NIC, I change the first GREEN NIC, to the RED rules…
When it was done, after this, and only after this, I was able to configure the second NIC as GREEN without the annoying NethGUI lost of connection.
For this reason, I make the suggestion to have the possibility to attribute the rule before going to the Nethgui for the first time, or make all the NICs RED ( by default, the access to the GUI on the RED side is authorised)…
That can resolve lot off issues… I think.
And close all by default is better, in the security point of view…
If you are aware of this fact… that’s ok.
You are probably thinking about a solution
But please, think about the case when Nethserver is configured only as Firewall Gateway
I would like to continue and to make some comments about the Nethserver 7…
I’m continuing to be surprise with the ergonomic and the (poor) logic in the NethGUI.
One exemple:
There’s the “applications” entry in the left menu bar, here’s there’s Lightsquid and Ntop.
Why not use the same logic, and use the “Application” entry, and put the “web Proxy Stat” here?
It’s exactly this lack of logic, this lack of ergonomy that let a not so good feeling about the NethGUI.
Actually, the “Application” menu is not well exploited… Is not entirely exploited.
I did you understand what I mean?
The reason for having such behavior is the following.
In early ns6 release there was no integration with Server Manager for such applications. They are accessible with a randomly generated URL only because it could be useful to share their URL with someone that is not an admin (your customer, for example).
Then came the Server Manager integrated view. But the sharing URL remains and is still available from “Applications”, as in origin.
If possible, move it to the new destination. It’s the simplest thing to do!
I’m not sure Samba follows symbolic links outside of the share path.
I didn’t experiment it, but I bet it works
From mount manpage:
The bind mounts.
Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is
mount --bind olddir newdir
or shortoption
mount -B olddir newdir
or fstab entry is:
/olddir /newdir none bind
After this call the same contents is accessible in two places. One can also remount a single file (on a single file).
This call attaches only (part of) a single filesystem, not possible submounts. The entire file hierarchy including submounts is attached a second place using
Edit 2: I tried to work around the Avahi configuration too…
But nothing seem to go ahead.
I tried too to modifying the SMB.conf, but
# vi smb.conf
# ================= DO NOT MODIFY THIS FILE =================
#
# Manual changes will be lost when this file is regenerated.
#
# Please read the developer's guide, which is available
# at https://dev.nethesis.it/projects/nethserver/wiki/NethServer
# original work from http://www.contribs.org/development/
#
# Copyright (C) 2013 Nethesis S.r.l.
# http://www.nethesis.it - support@nethesis.it
#
It was a real painful because there’s a conflict between Samba and Netatalk…
I was obliged to stop Samba, to create a user in the unix way, to configure the afp.conf with this user.
To be able to see the Backup resource in the Time Machine, and connect here.
Actually, even connect the shared folder in the Finder don’t work !!!
THere’s an error in the afp log
Jun 11 14:23:08.587677 netatalk[37882] {afp_avahi.c:131} (error:AFPDaemon): Failed to add service: Not supported
Jun 11 14:23:09.414782 afpd[37883] {dsi_tcp.c:320} (error:DSI): dsi_tcp_init(192.168.144.0/24): getaddrinfo: Name or service not known
Jun 11 14:23:09.414853 afpd[37883] {dsi_tcp.c:476} (error:DSI): No suitable network config for TCP socket
Jun 11 14:24:07.649626 afpd[37899] {dsi_stream.c:504} (error:DSI): dsi_stream_read: len:0, unexpected EOF
Jun 11 14:28:01.900195 netatalk[37929] {afp_avahi.c:131} (error:AFPDaemon): Failed to add service: Not supported
Jun 11 14:28:02.239113 afpd[37930] {dsi_tcp.c:320} (error:DSI): dsi_tcp_init(192.168.144.0/24): getaddrinfo: Name or service not known
Jun 11 14:28:02.239184 afpd[37930] {dsi_tcp.c:476} (error:DSI): No suitable network config for TCP socket
Jun 11 14:30:23.060420 netatalk[37972] {afp_avahi.c:131} (error:AFPDaemon): Failed to add service: Not supported
Jun 11 14:30:23.343714 afpd[37973] {dsi_tcp.c:320} (error:DSI): dsi_tcp_init(192.168.144.0/24): getaddrinfo: Name or service not known
Jun 11 14:30:23.343786 afpd[37973] {dsi_tcp.c:476} (error:DSI): No suitable network config for TCP socket
My temporary conclusion:
Samba as is installed in NethServer lack of some parameter to be compatible with the Apple Time Machine
Compiling Netatalk is ok, but there a conflict between Samba and Netatalk.
) I didn’t understand how to attribute the shared recourse in the Nethgui.
