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

Pages: [1] 2 3 ... 21
Installation and Upgrades / Re: Traffic shaping rate interval
« on: April 26, 2018, 05:17:42 pm »
Can someone please elaborate more on why I get this message when trying to reserve more bandwidth than 2400 kb/sec:

"Guaranteed Rate must be in this interval: ( 60, 2400 ) kbit/s"

I don't understand this limitation. Why can I not reserve 10mb/sec by putting in 10000?

I never completely fixed this, but I did discover that if I turn off the HTTP proxy the issue goes away.

The HTTP proxy shouldn't intercept port 80 traffic sourced from a VPN connection to a destination located on the LAN, but (for me) by default it does indeed do just that.

The HTTP proxy does allow "Transparent Proxy Exemptions", but only accepts domain names and since I'm trying to access this LAN's webserver via IP address, the Zentyal Web Interface doesn't seem to allow ip-base exemptions.

Installation and Upgrades / Re: Traffic Shaping in Zentyal 5.0
« on: January 03, 2018, 05:57:42 pm »
I'm still waiting for a reply on this. How do I implement traffic shaping on a Zentyal 5.0 gateway?

This is the only thing stopping us from Upgrading to 5.0. You see, our IP phone system requires priory on our network. We can't allow any user's bandwidth-intensive-activities to degrade VOIP call-quality on all the phones. Zentyal 4 provides the traffic shaping module and that works well for our VOIP prioritizing.

However, we cannot upgrade to Zentyal 5 until we know how to implement this same degree of VOIP prioritizing that we are currently enjoying in Zentyal 4.

Installation and Upgrades / Traffic Shaping in Zentyal 5.0
« on: March 20, 2017, 02:41:25 pm »
During installation, I'm not seeing the traffic shaping module I liked so much in previous versions of Zentyal:

Can you please direct me to documentation for how I might set this up in Zentyal 5?

Through a Zentyal 4.0 gateway, I'm trying to VPN-Access an interanet site located on a Windows Server at

Even when the windows firewall it turned off, I cannot access ports 443 and 80 via the Open VPN client. What's weird is that I can access all other ports on I can even RDP into this Windows sever via the OpenVPN client, but I cannot directly access the intranet that everyone else on-site can access. I've been getting around the issue by logging into a workstation that can access the intranet directly, but I'd like to figure out why I cannot access the intranet pages directly myself.

Any suggestions?

Installation and Upgrades / Re: Http Proxy- slow bandwidth issue
« on: December 07, 2015, 08:40:58 pm »
I've been using the Zentyal proxy since 4.0 came out. Today, I updated the server and the proxy stopped working; the service fails to start, and I had to disable the proxy altogether and save the configuration with proxy disabled before users regained the ability to browse web pages.

Update: I'm sorry. My issue was unrelated to yours.

After I performed apt-get updates on Zentyal 4.0.11 on 12-07-2015, the proxy service stopped and VPN was unaccessible.

I looked in the log:
tail /var/log/zentayl/zentyal.log

and I saw this error:
"Could not get ticket: could not acquire credentials using an initial credentials context: Password has expired"

According to this, the administrator password had expired:

Even though this server is no longer an official domain controller, I reset the password with the following command then
proxy and vpn began working again (after I re-enabled them):

sudo samba-tool user setpassword administrator

So, the update had nothing to do with this. If I had simply rebooted the server, I would have likely experienced the same issue.

Installation and Upgrades / Re: OpenVPN routing issues
« on: May 12, 2015, 06:59:58 pm »
Perhaps the server config did indeed change in 4.1; I don't know. However, I thought I'd mention this for comparison sake:

In Ubuntu, when you are setting up an Open VPN client config, there is a "Routes" button under the "IPv4 Settings" tab. When you click the "Routes" button, it provides this option:

 "Use this connection only for resources on its network"


Maybe this is unrelated, but I thought I'd mention it in case that it is applicable.

Yes, it is working now. I think I logged into a non-zentyal linux server (by mistake) previously.

Previously, in Zentyal 4.0, I could acquire the mysql password (for the squid database) using this command:
Code: [Select]
echo $(sudo cat /var/lib/zentyal/conf/zentyal-mysql.passwd)
After recent updates, it seems I've lost the ability to query the mysql squid database. I assumed, that somehow, the password got changed. And I've just noticed that the method I used (to retrieve the mysql password initially) no longer works; the path mentioned, in the command above, does not exist now.

Please advise.

Upgrading, from 3.0 to 3.2 was no issue for me.

From 3.2 to 3.3, after upgrade, the file server functionality required a bunch of custom fixes:,18179.msg70981.html#msg70981

From 3.3 to 3.4, I've never succeeded an upgrade until how I'll mention later.

From 3.4 to 3.5, I used the same method I'll mention later. So I can't say how good that goes with long-existing previous versions.

Here's how I finally got my 3.3.10 gateway (with vpn, firewall, traffic shaping, etc) to 3.5:

1) Because my gateway is on a physical machine (not a virtual machine), my first attempt failed and I had to reinstall 3.3.10 and restore my configuration.

2) With the physical machine running, I installed 3.3.10 into a virtual machine (Proxmox is was what I used, but the same could be done with virtualbox, hyper-v, or VMware). I made the virtual machine have the same number of network adapters as my gateway (In my case: 3).

3) I made sure that the virtual machine had the same Zentyal components installed as my live gateway.

4) I restored my gateway's zentyal-backup-configuration to this virtual machine. Then I changed the network-interface for the interface hosting the internal IP to "not set" (so it wouldn't conflict with the live gateway located on the same LAN).

5) In proxmox, I added a 4th network card to the virtual machine and rebooted the virtual machine. This additional network adapter became eth3 (for me) and set it to "dhcp" for acquiring an IP (for me dhcp service is host on other server in the LAN). This was need in order to have internet connection for upgrading later.

6) Since Zentyal is removing components, seemingly ever new release, I installed Zentyal 3.5 into a virtual machine just to see a list of what components it still has for a gateway install.

7) I remove each component in the 3.3.10 virtual machine that does not exist in 3.5.

8 ) I created another backup configuration from this 3.3.10 virtual machine.

9) I did a snapshot of this 3.3.10 virtual machine, so if my future attempt of upgrading fail, I can go back to this point without wasting time. Proxmox was wonderful for this, it not only did a snapshot, but it also snapshoted the RAM, so when I'd restore the virtual machine, it would already be running at the exact point I was at when I did the snap shot (Big Proxmox lover here).

10) I upgrade the 3.3.10 virtual machine to 3.4, and it succeeded. Unlike my live gateway, everything was freshly installed on this virtual machine, and so that likely has something to do with the upgrade succeeding.

11) Now that the virtual machine is 3.4, I did another snapshot, and also backed up it Zentyal-Backup-Configuration. Then I updated 3.4 as far as it would go, and did another backup of the config, saving it to my laptop. Then I did another snapshot of this virtual machine using proxmox.

12) I upgrade the 3.4 virtual machine to 3.5. It succeed, and I made a new backup of the 3.5 configuration.

13) I installed Zentyal 3.5 onto another physical machine having the same number of network adapters as my live gateway.

14) I restored the 3.5 configuration (that I made from that virtual machine), and put it onto this physical machine.

15) I change the internal interface back to its static internal IP (because remember that I had changed it to "not set" earlier).

16) I shutdown the live gateway.

17) I put the new physical machine, with the restored 3.5 configuration beside my (turned off) live gateway, and plugged all network cables into the correct ports.

18) I turned on the new physical server, internet didn't work at first because I had plugged cables into the wrong ports, but after I got the cables into the correct ports, the new physical machine, operated perfectly just like the Zentyal 3.3.10 physical gateway did. All firewall rules work, VPN worked, etc.

19) I did a backup of this physical machines 3.5 configuration, since it was functioning right as the gateway.

20) I re-installed Zentyal 3.5 on to the initial physical machine, and then restored the backup configuration (I made from the new running physical machine) to this initial gateway machine.

An that's all you have to do to upgrade Zentyal 3.3.10 to 3.5. You see, it is as simple as an android phone update (sarcasm intended).

This is an Ubuntu 14.04 bug:

But since Zentyal 3.5 and 4.0 are based on Ubuntu 14.04, it will effect some Zentyal admins too.

The key is to just wait. It will hang between 15 and 20 minutes and then continue.

From Zentyal 3.0 to 3.3.10, version upgrades predominantly succeeded in the Community edition.

Since 3.3.10, I have not been able to succeed in upgrading to 3.4 or 3.5.

I've also attempted installing 3.5 fresh, and restoring the 3.3.10 configuration to it. This is not supported.

This particular Zentyal server is functioning as a Gateway and providing OPEN VPN. Would it be easy to back up and restore just the VPN module protion of Zentyal 3.3 to a freshly installed 3.5?

I'm trying to avoid creating new keys/cert/etc. for all clients.

After using Zentyal successfully for 8 months as a domain controller and additional domain controller, this 3.4 update failed so bad that I've gone back to Microsoft for domain controlling.

The bare minimum I expect from Zentyal is that upgrades (that are called "releases") don't break domain controllers. When Zentyal calls something a release, translate that as "alpha", because that is the quality of most "releases".

Even on a clean install of 3.4 I could not join a workstation to the domain (much less an additional domain controller). I then install Windows 2008 R2 and succeeded with ease. Zentyal 3.0 was just as easy to set up as Windows 2008 R2. I've never seen a project regress so terribly as Zentyal.

I have high hope for the future, but their priorities are on their release schedule and not quality. They release "ready or not". They could learn a thing or two from projects like debian, who "when they call something a release" that means it is solid as a rock.

If something is not solid, call it a BETA or an ALPHA! Don't call it a release. If you dig, you'll see disclaimers about these "releases", but all this confusion finding these disclaimers can be avoided if they'd just use the terminology I'm suggesting for the "releases" that are not solid; call them beta releases!

If you use the community edition, you are genii pig destined for a broken environment.

Explain your set up more. You don't have use exact IPs, but use IPs that indicate what public and what's private. Questions:
1) Is eth0 set to External or Internal?
2) Is eth1 set to External or Internal?
3) Is the IP of eth0 public or private?
4) Is the IP of eth1 public or private?
5) Is is your fowarder forwarding from a public IP to private IP?
6) Are you external and internal interfaces on different subnets?

Typically your external interface will have a public IP or multiple public IPs via virtual interfaces.

Typically your internal interface has private IPs like 192.168.x.x

Typically your external interface in NOT on the same network as your internal interface. External is usually on a Public IP subnet and the internal is on a private IP subnet

Typically forwarders go from a Public IP to a Private IP.

This may not be typical for everyone, but has been typical for me.

If your public IP dynamically changes, I suspect you will have to create a network object that maps directly to you external interfaces MAC address and create forwards that go from that network object to the desired internal IP. This way, if you public IP changes, anyone who tries to access the new IP will still be forward to the proper internal IP and port.

Installation and Upgrades / Re: AD intigration witch samba failed
« on: May 26, 2014, 11:07:38 pm »
Based on this message:

ERROR(ldb): uncaught exception - LDAP error 68 LDAP_ENTRY_ALREADY_EXISTS -

it seems that perhaps you already have in your ldap an entry for the zentyal server name, have you checked this?

How do you check that using Zentyal?

Pages: [1] 2 3 ... 21