It is not the issue
# randomwait is used by yum to wait random time
# default is 60 so yum waits random time from 1 to 60 minutes
# the value must not be zero
RANDOMWAIT="60"
a random time is started to avoid that your NS clusters do the update at the same time 
For ns6 it is 60 minutes by default, for NS7 it is 6*60 minutes â 360 minutes.
the root recipient works well for ns6
for ns6
yum install http://mirror.de-labrusse.fr/NethDev/nethserver-yum-cron/nethserver-yum-cron-0.0.1-1.ns6.sdl.noarch.rpm
for ns7
yum install http://mirror.de-labrusse.fr/NethDev/nethserver-yum-cron/nethserver-yum-cron-0.1.3-1.ns7.sdl.noarch.rpm
You have several differences between ns6 and ns7, due to the yum-cron version. Some big changes has been done.
For both the default recipients is root now, the random starts is set to 60 minutes whatever the version, and this below is still right
By default, the notifications are sent and you download the updates. All notifications are sent to the root user. If you need it, you can direct the notifications on other email addresses, of course I can not do the settings of your smarthost, please verify in /var/log/maillog if you donât receive the emails, why they are bounced.
Each day a cron job starts during the night (after a random sleep time) and looks after update.
This is a good point! Indeed cron.daily implements a random timing and is executed also if the system is switched off by anacron.
great! thank you 
installed on my two NS7, and also on armv7hl and aarch64
I love that Steph, thanks for this new 
To avoid rejection I usually customize the sender address with something like root@real_email_domain
Some recipients check sender domain and refuse not resolvable or local domain
Yes it is customisable for ns7 but unfortunately not for ns6. If needed we can make a field for this settingsâŠletâs people break this module
Thanks a lot for that @stephdl . You are great!!
What do you think about adding a âConfigureâ button under the âSoftware Center > Updatesâ tab, instead of creating a new main menu entry?
What do you think about moving the âAdd custom recipientsâ text-area under âSend notificationsâ?
Also the âStatusâ checkbox could be removed.
Iâd prefer to arrange the fields like the following
(v) When updates are available
[ ] Download updates
[ ] Install updates automatically
Update method
[ default |v]
[ ] Send an email to the system administrator
Add custom recipients
+----------------------------------+
|
|
|
@davidep and @stephdl I like the way steph did it, because itâs clearly arranged in the menu. Easy to find. IMO to move it to softwarecenter/updates is a little bit to hide it.
IMO there is no need to move this area.
2 minor remarks:
I would rename the checkbox âStatusâ to âenable Serviceâ or so, if I understood this checkbox correct and to clearify who gets the notificationmail I think it would be good to add âto rootâ so it shows âSend notification to root@domain.tldâ. But this would be only minor cosmetic. The modul itself is great!
Iâd prefer Davideâs proposal, with the emails tied to an expandable fieldset switch
I tried, but I missed something and my tab was not displayed,âŠSince I wanted to do a workable POC, I went to the code directly but I tend to agree and I will need probably your help. That said, even if I love to reuse an existing menu in the panel, I saw that the software center needs a really long time for the first usage to display the panel. I do not know for the other time, but I worry if you need to just have a quick access to modify something, to waste time, waiting the yum update.
agreed
I donât understand why ? someone could want to stop the service
yes agreed
I would prefer to stick to the @davidep proposal : system administrator
Because the actual Status value can be inferred from the state of either âDownload updatesâ or âSend notificationsâ. No need to ask it to the user.
Youâre right, it can be too slow for that task. Well I hope we can improve and speed it up before the ISO release: it would be a great enhancement to the Software Center page!
Yes it is valid for the ns7 version, then you launch the service which does nothing and it ends several seconds after. It is less clear (from my point of view) than a check box enable/disable service.
However for ns6 it is really different because you donât have the same settings.
for ns6 you control with
CHECK_ONLY=no
DOWNLOAD_ONLY=no
it is the default start which means download and install
The ns7 version is really cool with many, many more settings
yes you could be right for ns7
new UI for ns6 and ns7, hope it is more clear
for ns6
yum install http://mirror.de-labrusse.fr/NethDev/nethserver-yum-cron/nethserver-yum-cron-0.0.2-1.ns6.sdl.noarch.rpm
for ns7
yum install http://mirror.de-labrusse.fr/NethDev/nethserver-yum-cron/nethserver-yum-cron-0.1.4-1.ns7.sdl.noarch.rpm
I dug deeper into the subject, to prevent excessive load on mirrors due to clients downloading updates and metadata at the same time.
Upstream defaults for anacron and yum-cron:
In other words, a CentOS server that is not switched off overnight starts yum-cron from 3.05 AM up to 9.50 AM, local time.
The 6 hrs random delay locks the cron.daily job for a long time, and I donât like this aspect. I can see the evidence of it in my log files.
However, NethServer Enterprise runs the CentOS default value. It proved to work well against Nethesis mirrors. For this reason Iâd apply the same 6 hrs delay to the Community edition, too.
For ns7
random time back 360 minutes
recipient text area resized to 5x30
the dropdown selector has been moved outside of the download checkbox
yum install http://mirror.de-labrusse.fr/NethDev/nethserver-yum-cron/nethserver-yum-cron-0.1.6-1.ns7.sdl.noarch.rpm
For ns6
no change
yum install http://mirror.de-labrusse.fr/NethDev/nethserver-yum-cron/nethserver-yum-cron-0.0.2-1.ns6.sdl.noarch.rpmbumpâŠno bugs on it ???, it is curious.
Please test yum-cron available for ns6 and ns7