Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - peptoniET

Pages: [1] 2
Directory and Authentication / Re: samba audit?
« on: April 28, 2020, 08:44:12 am »
local7.*    /var/log/audit.log
& stop

Other modules / Re: DNS - user problem - restart
« on: February 08, 2019, 12:41:55 pm »

So, dns-SRV01 (in other cases dns-SERVERNAME) user had dissappeared.  Why?  I will never know.  Certainly, nothing that i've done so far.

Hope this helps others.

To recreate:

Create user again
Code: [Select]
samba-tool user create dns-SERVERNAME
Add user to dns admin group
Code: [Select]
sudo samba-tool group addmembers DnsAdmins dns-SERVERNAME
Rename dns.keytab file
Code: [Select]
sudo cp /var/lib/samba/private/dns.keytab /var/lib/samba/private/dns.keytab.old
Delete dns.keytab file
Code: [Select]
sudo rm /var/lib/samba/private/dns.keytab
Re-create dns.keytab file
Code: [Select]
sudo samba-tool domain exportkeytab --principal=DNS/SERVERNAME.DOMAINNAME.LAN /var/lib/samba/private/dns.keytab
sudo samba-tool domain exportkeytab --principal=dns-SERVERNAME@DOMAINNAME.LAN /var/lib/samba/private/dns.keytab

Add dns user credentials
Code: [Select]
sudo kinit -k -t /var/lib/samba/private/dns.keytab dns-SERVERNAME
View result file
Code: [Select]
sudo ktutil -v -k /var/lib/samba/private/dns.keytab list
Change group and permissions of the result file
Code: [Select]
chmod 640 /var/lib/samba/private/dns.keytab
chgrp bind /var/lib/samba/private/dns.keytab

After all these, DNS restart does not give any errors.

Other modules / [SOLVED] DNS - user problem - restart
« on: February 08, 2019, 10:05:33 am »
This is the situation:

Installed Zentyal 6 as main domain controller SRV01
Installed Zentyal 6 on another machine as domain member SRV03
After installing domain memeber SRV03, restarting the DNS module on SRV01 from the web gui, yields error.

Error is:
Code: [Select]
2019/02/08 07:40:13 ERROR> EBox::Sudo::_rootError - root command nsupdate -g -t 10 /var/lib/zentyal/tmp/fP_eCW54tO failed.
2019/02/08 07:40:13 ERROR> EBox::Module::Service::restartService - Error restarting service: root command nsupdate -g -t 10 /var/lib/zentyal/tmp/fP_eCW54tO failed.
Error output: tkey query failed: GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more information, Minor = No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0).

Changes to DNS are saved and visible on web gui, but not really saved to DNS server.

On SRV01 "samba-tool user list" shows "dns-srv01" dissappeared, but "dns-SRV03" exists!
On SRV03 "samba-tool user list" shows "dns-SRV03" exists.

Tried to create user "dns-srv01" on SRV01 and add it to "DnsAdmins" group with no luck, but error is different:
Code: [Select]
2019/02/08 09:24:08 ERROR> EBox::Module::Service::restartService - root command kinit -k -t /var/lib/samba/private/dns.keytab dns-srv01 failed.
2019/02/08 09:24:08 ERROR> EBox::SysInfo::CGI::RestartService::_process - Restart of DNS from dashboard failed: root command kinit -k -t /var/lib/samba/private/dns.keytab dns-srv01 failed.
Error output: kinit: Password incorrect

Directory and Authentication / Re: zentyal bacup restore
« on: November 13, 2018, 07:44:01 am »
This might happen because when you installed Zentyal before restore, you used the same admin username as in the original installation.  Re-install with a different username for admin and it should work.

Found a solution, but don't know why it's behaving this way.

On the DHCP module, the WINS server option was enabled, setting "local Zentyal" as WINS server.

Setting WINS server to "none" completely solved the problem.

During the wait periods, there is no disk activity, not network activity, neither on the source nor on the zentyal server.

Smells like a timeout trying to find something...

Five Windows 10 workstations with exactly the same behaviour.


Just installed my first Zentyal 6, after many years using previous versions.

First login of users (profile creation) from Windows 10 takes more than 10 minutes.  Logins after use up to 2-3 minutes.

Any user/permission related action is very slow (like 2-3 minutes.  For example, delete an admin installed shortcut in the desktop from a non admin account.  It takes ages to ask for an admin account.

Any clues? Thanks

Thanks for pointing the missing wget, I've edited the post.

About the Zentyal 5.1 repositories, nothing "happened" to them, there was no change at all in their content in the last days (mainly because the team was focused in the release of Zentyal 6.0). In fact, those "conflicting packages" (libapt-pkg5.0 and libapt-inst2.0) have been there for a full year (introduced as dependencies of the samba 4.7 packages from a newer version of Ubuntu before the release of Zentyal 5.1) causing no problem at all during this whole year.

The problem arose the other day as a result of the release of newer apt packages to the Ubuntu xenial-updates repo, and as the version from libapt-pkg5.0 in the Zentyal repo was greater than the correct one in xenial-updates, apt was left in a broken state after the upgrade. The solution has been just deleting those packages from the repo, as they were no longer needed because currently with the newer packages from Ubuntu all the dependencies were already satisfied.

Finally, as I said in my previous post, the "real fix" is not having any packages with newer version in the Zentyal repo than in the Ubuntu ones in the newest Zentyal 6.0, so this release is definitely "protected" against these problems.

Hope this clarifies the issue.


For me, it does clarify very well.  Thanks for you prompt and clear answer.  Sure it means a lot to the community who relies in a stable Zentyal.

thanks a lot.

Gracias por tu buen talante.

Great news to know you have solved your mistake.  Yesterday I found the solution on my own, after several hours fighting, and having several servers afected.

By the way, you might like to correct your quote about a solution:  you are missing a "wget".  The original poster did include the wget.

Would you care to explain exactly what happened to the repositories you maintain?  What was the procedure that went wrong?  This is a relevant error and the community would be grateful if you could explain, not only what went wrong, but what did/will you do to ensure it will not happen again.

I'm sure a complete explanation from you will benefit the Zentyal organization, showing a transparent communication.

Thanks in advance.

I cannot afford to disable root mails, so I've gone through this solutions instead.

Code: [Select]
* * * * * root /usr/bin/net cache flush &>/dev/null
But I'm still worried about the error messages...

I would not remove this entry.  Zentyal team has put it there for some powerful reason...  you don't clean the cache every minute for nothing...

More about this here:

But that is back to November 2015...

Ok then.  This s**t was introduced by zentyal-samba 4.2.3.  >:(

OK.  I forgot I had another server which I have not upgraded this module to 4.2.3.

THERE IS NO /etc/cron.d/zentyal-samba IN 4.2.2!!!

What kind of problem Zentyal has that it has to clear the cache EVERY MINUTE???  It's an insane method...

I guess we could modify the line like this

Code: [Select]
* * * * * root /usr/bin/net cache flush &>/dev/null
to get rid of the mails,

BUT: How relevant are this messages?  Could not find any info on them...

Anybody has a 4.2.2 module and check if there is this cronjob there too...?

Pages: [1] 2