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 - Giblet535

Pages: [1] 2
Wow. 7 is not ready for release, and upgrade is very broken.

Hint: making installation images (for a router) that require an internet connection to install... Try it.

I'm back on 6.2 so it's [SOLVED].

I ran through the 7 upgrade docs. Checked what it suggests. I don't see any problems.

I'm watching zentyal.log, and nothing gets logged when the system stops routing WAN traffic.

If I click a "Change" button for an interface, the orange Save button lights up. Clicking that gets things working again for another 10 minutes. It takes about five minutes.

Syslog gets a LOT of entries.

Is there something I should look for, explicitly?

I upgraded from 6.1 to 6.2 about a month ago. My system updates manually.

Have there really been no updates to Ubuntu - none at all - in a whole month? That's not how Ubuntu works. That's not how any of this works.

I'm thinkin' my apt sources are busted... I get no errors from 'apt update', but that "All packages are up to date." message at the end is creepy and dystopian.

Is there an easy way to put them back to stock?

Edit: Or, is possible that Zentyal is ignoring my setting for Automatic Updates?

I mean, my sources.list looks OK.
Code: [Select]
Hit:1 6.2 InRelease
Hit:2 jessie InRelease
Hit:3 6.1 InRelease
Hit:4 bionic InRelease
Hit:5 bionic-updates InRelease
Hit:6 trusty InRelease
Hit:7 bionic-backports InRelease
Hit:8 public InRelease
Hit:9 bionic InRelease
Hit:10 bionic-security InRelease
Hit:11 xenial InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.

Installation and Upgrades / [SOLVED] Re: Upgrade from 5.1 - dpkg fails
« on: December 06, 2019, 02:34:33 pm »
I set up a temporary /etc/fetchmailrc to poll the Zentyal server.

That allowed
Code: [Select]
dpkg --configure fetchmailto succeed, so the the remainder of the upgrade can continue.

Installation and Upgrades / [SOLVED] Upgrade from 5.1 - dpkg fails
« on: December 06, 2019, 02:11:26 pm »
I upgraded from 5.1, which upgrades Ubuntu to 18.04LTS.

dpkg fails with:
Code: [Select]
fetchmail: no mailservers have been specified.

This causes all of the Zentyal mail packages to fail to configure. The upgrade is stuck at around 98% completion...

I don't use any fetches from other mail servers, and probably never will, so of course no mailservers are configured!

How can I get around this?

Zentyal 4.2...

If an outsider requests mail relay and the message's "From:" includes one of Zentyal's configured virtual domains, then postfix will relay that email, no authentication at all.

I have fairly restrictive rules set in /etc/postfix/
reject_non_fqdn_recipient, reject_non_fqdn_sender, reject_unlisted_recipient, reject_unauth_pipelining, permit_sasl_authenticated, reject_unauth_destination, reject_invalid_hostname, reject_invalid_helo_hostname, reject_unknown_sender_domain, reject_unknown_recipient_domain, check_helo_access pcre:/etc/postfix/helo_checks.pcre

Not even local host should be able to relay w/o authenticating and yet I can see mail being relayed in /var/log/mail.log! One way to relay, a dozen ways to fail... Yet it's like an open relay!

I see no authentication messages in mail.log, and I suspect that Zentyal's authentication mechanism through LDAP is broken somehow.

Please. Someone help me troubleshoot this before anyone else gets spammed.

Suddenly, it now works 7 times in 10. I dub thee Mabe! Mabe email.

I did nothing, so I can't offer any hints.

Installation and Upgrades / Re: outlook 2010 push issues
« on: August 10, 2015, 04:25:31 pm »
Zentyal doesn't work with Outlook in Exchange mode. IMAP, sure. POP3, sure. Zentyal says it works in Exchange mode, but it doesn't as you can easily see.

There is hearsay that the paid and demo versions supports Outlook in Exchange mode, but I'm not going to pay to find out.

Installation and Upgrades / Can't send email - Postfix is not happy
« on: August 10, 2015, 03:56:39 pm »
4.1 install has worked fine for about a year through several upgrades.

This morning, I can't send email. I can receive email in webmail/Outlook/Win10email, but can't send.

/var/log/mail records this error:
timestamp server postfix/sendmail[NNNNNNN]: fatal: usage: sendmail [options]

It looks to me like translating to postfix, Zentyal/OpenChange is using the wrong options to postfix/sendmail.

Is your RAID1 array managed in software, or with a hardware RAID controller?

Is write cache enabled on this array? Is EXT4 journaling disabled on this array? Those two options are often employed to improve performance. Each will decrease reliability by about the same amounts. RAID1 however is an increased reliability / low price, low performance configuration.

How do you power off? If you use the power button, and disable journaling, and enable write caching, you will lose data every time you power down.

sudo /sbin/poweroff should provide a completely safe power down for any drive or array except for remote arrays (NAS/SAN arrays, and optically-attached storage).

This workstation is using 2 Corsair SSDs in software RAID1 for the / filesystem (ext4). Write-thru cache is not an option, journaling is enabled, ATIME is disabled. It sleeps, restarts, and powers off without any issues for over two years now. It sleeps on weeknights, powers down on weekends.

Was there a resolution for this?

I'm getting between 10 - 20 of these ebox emails every second.

They originate in /var/log/auth.log, which is full of PAM errors from dodgy installation. (Zentyal 3.4 image, patched to Zentyal 4)

I'd like to stop the nonsense warnings, rather than only stop the nonsense warnings from being emailed to root.

After all: If we always ignore wasted system resources, the inevitable result will behave like Microsoft Windows.


My Solution: I deleted pre-upgrade 3.X fetchmail configuration from /etc/fetchmailrc and restarted fetchmail.
This stopped the flood of emails.

Installation and Upgrades / [SOLVED] 1000's of Ebox messages to root
« on: January 26, 2015, 06:14:35 pm »
The root user is receiving emails from ebox@localhost at a rate of 8-20 per second.

They all contain the same message:
ebox : problem with defaults entries ; TTY=unknown ; PWD=/ ;

There appear to be bug reports about this, it looks like the devs don't believe the reports, and I have found no corrective action.

How do I stop this? I prefer to fix it vs hiding it, but there's not much information pointing at a cause.

An older release of Zentyal had created a /etc/fetchmailrc file to fetch email from a remote server.

I know that I deleted this entry in the old (3.4, I think) Zentyal release, and that it no longer appeared in the UI. It was that orphaned entry that was causing the ebox errors.

I deleted the entry and restarted fetchmail. Problem solved.

Installation and Upgrades / Re: NTP Server Config in Lab Environment
« on: January 26, 2015, 04:23:44 pm »
Check the comments in It explains how to fudge the clock.

Difficulty: Ubuntu 9.10

NTP configuration hasn't changed much though.

Can you log in via webmail?

No: ActiveSync is not the problem. Check your mail domains.

Yes: Use the same user and password for ActiveSync.

There are internet domains (,, etc), and there are Microsoft domains (mail.lan, local.lan). They are completely unrelated.

Microsoft domains only work on local area networks (or VPN tunnels to those local area networks - which is the same thing).

If you're trying to authenticate using me@somemickeymousedomain.lan, then that is the problem. That domain has no meaning when you're 1000 miles from your office, and ActiveSync is a mobile device protocol.

Try using your internet domain name e.g.,

Log in via webmail. If that works, then ActiveSync should work using the same credentials (if ActiveSync is enabled for that virtual mail domain).

Up until today, and new with Zentyal 4, the mail subsystem had to be restarted before email could be sent (TBird, webmail, Android).

Until today, Mail always displayed in the dashboard as "Running" whether it worked or not.

Today, it shows as "Stopped". The "Start" button displays that starting Mail was successful, but the status still displays "Stopped".

Yet I can send and receive email (for now).

Can someone explain why there are three mail subsystem categories in the web admin user interface? (OpenChange, Mail, and Mail Filter?) Did that really make sense to someone?

How do I troubleshoot "Mail" problems?

I had added an external email account (Google) to fetch email from.
Removing that account allows the Mail subsystem to display as "Running" and it still works.

This appears to be an identical bug to the one in the 3.5 release.

This still doesn't explain why there are three Mail subsystems in the user interface, but then I have not seen the UI team's automobiles: they might have separate Left-Turn, and Right-Turn steering wheels plus a Turn-Stick labeled with arrows pointing up and down. So, not enough data.

Pages: [1] 2