Topics

1

Installation and Upgrades / New 2.1 installation zentyal-services failure:

« on: June 21, 2011, 05:34:50 pm »

Attempting to install upon 2.6.35-30-generic based Lucid, due to 2.6.32's continued failures to deal with the default ext4 correctly...

Preparing to replace zentyal-services 2.1.1 (using zentyal-services_2.1.1_all.deb) ...
Unpacking replacement zentyal-services ...
Setting up zentyal-services (2.1.1) ...
This service has no protocols configureddpkg: error processing zentyal-services (--install):
 subprocess installed post-installation script returned error exit status 255
Errors were encountered while processing:
 zentyal-services

2

Installation and Upgrades / Dashboard Bandwidth Graphs not updating, after updates

« on: December 07, 2010, 06:19:38 pm »

As of 06 December 2010's updates, the issue described in this thread (http://forum.zentyal.org/index.php?topic=1865.0) seems to be back.

She's the gateway to a network that is currently running 2 scp operations to public hosts via VPN, each at ~40 KiBs/sec, among other things (just plain surfing, Hulu, etc...), and after HOURS of leaving the dashboard open, the graphs still sit at 0b.  After I noticed this, I played with it a little, and once or twice, they would do the odd thing where the lines suddenly drop to bottom, and at the far right end, shoot sharply up to top right corner.  Then, however, they freeze in that position.

Again, not too terribly large an issue for me, but it may be for others...

3

Installation and Upgrades / Disabling DHCP Module DOES NOT DISABLE IT [SOLVED]

« on: November 30, 2010, 12:19:28 am »

I, occasionally, need to use the DHCP Service, to issue a small IP range, for a SHORT time.

This is a TEMPORARY need, and NEEDS TO BE TEMPORARY.

So, I enable the DHCP Service, set up a range to be issued from, and when done, disable the DHCP Service, but CONTINUE to see that very range of IP's issued, afterward...

When I disable something, I expect it to BE DISABLED.

4

Installation and Upgrades / Groups CANNOT have spaces or special characters in name [was: RADIUS fails...]

« on: November 04, 2010, 05:46:41 pm »

If, once I've created users / groups as needed, I then change the RADIUS Module to only allow certain group to auth, it fails to save / start.

This first became apparent on my Lucid-Server (upgraded thru 3-4 versions of Kubuntu), and I could not pin the cause down to change in group.  Hosed Zentyal install, trying to fix, and as a result, I've just rebuilt my entire server, due to this issue, and now have found it not to have been necessary...

I've now got a new install of 2.0.6, installed from cd, in VirtualBox, and noticed the same issue again, as soon as I changed allowed group to other than All Users.

It DOES return to operational, after changing back to All Users, thank goodness...

This is a bit frustrating, as I'm not so sure I want ALL the users I may create (backup clients, external / extended family, neighbors) to auth to my WiFi AP...

5

Installation and Upgrades / [FIXED, sort of, as of 2.0] Ebox 1.5 RADIUS and IDS Modules cannot be started...

« on: July 29, 2010, 06:34:13 pm »

Neither of these modules has EVER started for me, since installing them on my server (within days of their release on the ppa...).  Wondering if this might have to do with Ubuntu's upgrade to Upstart?

uname -a = Linux dev 2.6.32-24-server #38-Ubuntu SMP Mon Jul 5 10:29:32 UTC 2010 x86_64 GNU/Linux

dpkg -l | grep "ebox-" = http://paste.ubuntu.com/470748/

cat /var/log/ebox/ebox.log = (just relevant bits) http://paste.ubuntu.com/470751/

6

Installation and Upgrades / HOWTO: IPv6 Tunneling (Did NOT work, first attempt, Zentyal 2.0)

« on: January 27, 2010, 09:03:04 am »

It's been a battle, but I've got a successful tunnel, persistent thru reboots, on eBox (1.3.15, but version should not matter).

My tunnel is a tunnelbroker.net /64 (I have 2x /48's, 2x /64's, but lets keep this simple!).  All IP info, of course, is obscured, and should be replaced by your own.  Also, $LAN will be used to denote internal iface, $WAN to denote external.  This is not complete, by any means.  Please, feel free to add / argue / contradict where appropriate, or just 'cause ya' don't like me!!

My tunnel info:

Code: [Select]

Global Tunnel ID:  12345 Local Tunnel ID: 123
Tunnel Endpoints
Server IPv4 address: 123.456.789.2
Server IPv6 address: 2001:456:abc0:123::1/64
Client IPv4 address: 98.76.54.32
Client IPv6 address: 2001:456:abc0:123::2/64
Available DNS Resolvers
Anycasted IPv6 Caching Nameserver: 2001:470:20::2
Anycasted IPv4 Caching Nameserver: 74.82.42.42
Routed IPv6 Prefixes and rDNS Delegations
Routed /64: 2001:456:abc1:123::/64And, here's their example config, for linux-route2:

Code: [Select]

modprobe ipv6
ip tunnel add he-ipv6 mode sit remote 123.456.789.2 local 98.76.54.32 ttl 255
ip link set he-ipv6 up
ip addr add 2001:456:abc0:123::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr
Here's what I did, that worx (please note old and new.  Old way was flaky, as the firewall default DROP policy loads AFTER Network loads, and only permits NEW connections of allowed sort.  Thus, the tunnel being already connected, it is blocked, it seems, much of the time):

OLD WAY:

Code: [Select]

sudo vim /etc/ebox/hooks/network.postsetconfNEW WAY:

Code: [Select]

sudo vim /etc/ebox/hooks/firewall.postsetconfIn that file, I've entered

Code: [Select]

#!/bin/sh
###When I get it all figured out, the following commented lines will automatically update my tunnel endpoint address, when it changes:
#https://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=$IPV4ADDR&pass=$MD5PASS&user_id=$USERID&tunnel_id=$GTUNID
#$IPV4ADDR = The new IPv4 Endpoint (AUTO to use the requesting client's IP address)
#$MD5PASS = The MD5 Hash of your password
#$USERID = The UserID from the main page of the tunnelbroker (not your username)
#$GTUNID = The Global Tunnel ID from the tunnel_details page
ip tunnel add he-ipv6 mode sit remote 123.456.789.2 local 98.76.54.32 ttl 255
ip link set he-ipv6 up
ip addr add 2001:456:abc0:123::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -6 addr add 2001:456:abc1:123::1/64 dev $LAN
echo "nameserver 2001:470:20::2" >> /etc/resolv.conf
exit 0Save and exit that file, then:

Code: [Select]

sudo chmod +x /etc/ebox/hooks/firewall.postsetconfAt this point, the next time you make any changes to your network settings, and save them, your tunnel will be created, and every time thereafter.

We're not quite done, tho.  The default firewall settings will not permit tunnelbroker.net to ping our $WAN ip, to verify it's validity, nor will it permit any traffic from the $WAN, over the tunnel.  I'm not sure quite what the correct way to define Protocol 41 for the firewall, so I've simply created rules from "External to eBox" permitting all ICMP from the IP on the IP-Update page (click your "Client IPv4 address:    98.76.54.32"), and ALL traffic from the Server Endpoint IP (Probably NOT the safest thing to do!!).

Voilla!  Next reboot (sorry for the profane language), or next edit/save of network settings, and your tunnel should be golden!  Now, for setting up the network behind it...  To begin with, here:

Code: [Select]

sudo vim /etc/sysctl.confLocate the line that reads

Code: [Select]

#net.ipv6.ip_forward=1, and UN-comment it (remove the #).

On server, as well, install radvd

Code: [Select]

sudo aptitude install radvd
Then,

Code: [Select]

sudo vim /etc/radvd.confand paste this in:

Code: [Select]

interface lan
{
   AdvSendAdvert on;
   MinRtrAdvInterval 3;
   MaxRtrAdvInterval 10;
   prefix 2001:456:abc1:123::/64
   {
        AdvOnLink on;
        AdvAutonomous on;
        AdvRouterAddr on;
   };
};
Now, eBox will provide IPv6 addresses, to the internal network, hopefully even the VPN clients...

Hope this might help someone out!!  Happy Hackin'!!

edit:  code-snippets don't respect formatting flags...  removed.
edit2:  Added edit to sysctl.conf, to permit forwarding

edit3:  Added radvd.conf, for those who might need it.

7

Installation and Upgrades / Apologies, for my attitude in previous posts...

« on: December 27, 2009, 11:33:23 am »

As I'm sure you're all aware, I'm new here.  I've arrived with less than the best attitude, and my first few posts have reflected that, upon all of you, and I do apologize.

I'd like to take this opportunity to explain (NOT excuse) where I'm coming from, if I may.

I've been peripherally involved (as user / tester / tweaker / breaker / reporter-of-breakages / wisher-for-more / wannabe-Tim-Taylor) with a few other projects, one of which I'll stick with, the others of which eBox will replace, for me, in my 3/4-Decade in the wonderful world of FOSS.

I apologize anew, for the fact that I'm not yet capable of development, but I do most of what I've listed above, quite well (particularly the breaking part), when it comes to software.

My attitude comes from this concept:  If you claim to be something, BE IT, or BECOME IT QUICKLY.

In my first day playing with eBox, it has shown itself NOT to be fully capable of such STANDARD technologies as DHCP (client-side) and PPPoE.  Lotsa' promise these things are being fixed, MONTHS AGO, but nothing's actually BEEN DONE, from a users' perspective, and these technologies are OLD-SCHOOL...

Future technology IS coming, whether we like / need it or not, such as IPv6, and this guy's thread got moved, but never acknowledged or replied to, http://forum.ebox-platform.com/index.php?topic=444.msg1607#msg1607, from July 09, 2008, A YEAR AND A HALF AGO...  REALLY?  OK, so we'll just wait around, until we're a few months (or years) TOO LATE, to work on it?  Or, even ANSWER THE GUY?  WOW...

So, before I'd spent a full day researching / testing this project for my customers' and my own use, I've already run into 2 HUGE examples of the same negative stance, lack of care, and lack of progress that I've experienced with other projects that I've walked away from, and seen others driven from, by the very same.

Is this the path that FOSS is on?  Can we imagine where this path leads?  I sure can...  No wonder all my clientelle are scared to death to leave their Gated yards and Closed Windows...  They don't want to wait around for a year and a half to be told that they're screwed, they'd rather get it right up front...