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.
Pages: [1] 2
1
Contributions / Tips&Tricks / Features Requests / Re: [Feature Request] IPv6
« on: February 21, 2017, 04:35:51 am »
**BUMP**
I think most places support IPv6. There was support for World IPv6 Day (June 8 2011) and talk of putting the feature in 2.3, but it's continually kicked down the road. It's disappointing that the feature didn't make 4.0 or even 5.0. There are a lot of things I like about Zentyal, but I may have to abandon it if they don't offer support later this year. It's getting harder and harder to work around not having it, and the technology is from last century.
I think most places support IPv6. There was support for World IPv6 Day (June 8 2011) and talk of putting the feature in 2.3, but it's continually kicked down the road. It's disappointing that the feature didn't make 4.0 or even 5.0. There are a lot of things I like about Zentyal, but I may have to abandon it if they don't offer support later this year. It's getting harder and harder to work around not having it, and the technology is from last century.
2
Installation and Upgrades / Re: Zentyal-to-Zentyal tunnel connecting 2 LAN's
« on: April 20, 2013, 01:27:58 am »Aside of the glitch of the documentation, the typical error here is that hosts on one LAN don't have a return route to the other LAN. The easier way to rule this is to have the Zentyal server as default gateway; if this is not possible you have to create explicit routes to the other LAN using the Zentyal as gateway,
If I make Server 1 the default gateway, I lose 30-40% of my download speed on Server 2. It's possible, but a bad idea. I don't see anything missing from my route that I need to create. I deleted the public IP's and default gateways from the list below for privacy.
Server 1 is hosting the VPN, and is only configured to be advertising 192.168.1.0/24. Somehow the VPN link is also advertising 10.202.0.0/20 and 192.168.160/24, since it only comes up when that VPN is connected. I assume tap0 on Server 1 and virbr0 on Server 2 have to do with my Zentyal subscriptions, since I didn't set up anything like that.
Server 1 (data center - Zentyal 2.2)
LAN IP: 192.168.1.1
VPN IP: 192.168.250.1
Advertised network: 192.168.1.0/24
Code: [Select]
tap0 Link encap:Ethernet HWaddr 6a:c2:fe:06:2c:81
inet addr:10.202.3.212 Bcast:10.202.15.255 Mask:255.255.240.0
inet6 addr: fe80::68c2:feff:fe06:2c81/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:720 (720.0 B)
tap1 Link encap:Ethernet HWaddr 4e:e1:e9:f5:e9:f2
inet addr:192.168.160.1 Bcast:192.168.160.255 Mask:255.255.255.0
inet6 addr: fe80::4ce1:e9ff:fef5:e9f2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:24219 errors:0 dropped:0 overruns:0 frame:0
TX packets:22100 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:3720565 (3.7 MB) TX bytes:4981028 (4.9 MB)
tap2 Link encap:Ethernet HWaddr 06:cf:a8:0a:18:f6
inet addr:192.168.250.1 Bcast:192.168.250.255 Mask:255.255.255.0
inet6 addr: fe80::4cf:a8ff:fe0a:18f6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:270 errors:0 dropped:0 overruns:0 frame:0
TX packets:489 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:31708 (31.7 KB) TX bytes:68374 (68.3 KB)
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 192.168.250.2 255.255.255.0 UG 2 0 0 tap2
192.168.160.0 * 255.255.255.0 U 0 0 0 tap1
192.168.250.0 * 255.255.255.0 U 0 0 0 tap2
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
192.168.122.0 192.168.250.2 255.255.255.0 UG 2 0 0 tap2
10.202.0.0 * 255.255.240.0 U 0 0 0 tap0
10.200.0.0 10.202.0.1 255.255.0.0 UG 0 0 0 tap0Server 2 (dev office - Zentyal 3.0)
LAN IP: 192.168.2.1
VPN IP: 192.168.250.2
Code: [Select]
tap0 Link encap:Ethernet HWaddr 66:58:03:4d:6e:56
inet addr:192.168.250.2 Bcast:192.168.250.255 Mask:255.255.255.0
inet6 addr: fe80::6458:3ff:fe4d:6e56/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:354 errors:0 dropped:0 overruns:0 frame:0
TX packets:186 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:50284 (50.2 KB) TX bytes:22944 (22.9 KB)
virbr0 Link encap:Ethernet HWaddr 36:26:0a:0e:79:af
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.202.0.0 192.168.250.1 255.255.240.0 UG 2 0 0 tap0
192.168.2.0 * 255.255.255.0 U 0 0 0 eth4
192.168.122.0 * 255.255.255.0 U 0 0 0 virbr0
192.168.160.0 192.168.250.1 255.255.255.0 UG 2 0 0 tap0
192.168.1.0 192.168.250.1 255.255.255.0 UG 0 0 0 tap0
192.168.250.0 * 255.255.255.0 U 0 0 0 tap0
3
Installation and Upgrades / Re: Zentyal-to-Zentyal tunnel connecting 2 LAN's
« on: April 19, 2013, 05:29:31 pm »
When I look at the routes on both servers, everything looks okay . When I look at the NAT iptable (`iptables -L -t nat`), everything looks okay on both servers. There are a lot of things listed in iptables, so I could easily miss something.
4
Installation and Upgrades / Re: Zentyal-to-Zentyal tunnel connecting 2 LAN's
« on: April 19, 2013, 02:10:16 pm »
I got my virtual environment set up and configured. Everything is working fine there, so I guess I'll have to start digging around at settings. The problem is I'm not sure of much to look at, besides replicating more of my settings in the virtual environment. The routes and NAT iptable look okay, but there is a lot in the iptables.
I did find and file a minor bug (here) on the UI for adding a new VPN Client, but the worst the bug will do is confuse someone.
I did find and file a minor bug (here) on the UI for adding a new VPN Client, but the worst the bug will do is confuse someone.
5
Installation and Upgrades / Re: Zentyal-to-Zentyal tunnel connecting 2 LAN's
« on: April 16, 2013, 10:57:16 pm »
I'll try configuring everything with fresh installs, using a virtualized environment. If my virtual setup works, then I know I've probably done something wrong with the systems that is breaking things. With the other projects I have going, it might be a day or two before I get everything finished.
Once I get the VPN up, I'll probably just manually clone the important parts of the two DNS zones.
Once I get the VPN up, I'll probably just manually clone the important parts of the two DNS zones.
6
Installation and Upgrades / Re: Zentyal-to-Zentyal tunnel connecting 2 LAN's
« on: April 16, 2013, 05:14:22 pm »
I wanted to make sure that I'm clear on what it should be doing and what it is actually doing, and I agree with your suggestions on how to proceed.
You are correct on the DNS and DHCP services. I think the push statements are merely suggestions, but either way, the Linux client program defaults to ignoring any DNS and DHCP options that are pushed. The Windows client program defaults to accepting the pushed statements. I just brought it up because I have had problems in other situations that were caused small customizations that I didn't think mattered.
Thank you for looking in to this. I'm sorry if I'm not more help in the problem, but my primary job is with software development.
You are correct on the DNS and DHCP services. I think the push statements are merely suggestions, but either way, the Linux client program defaults to ignoring any DNS and DHCP options that are pushed. The Windows client program defaults to accepting the pushed statements. I just brought it up because I have had problems in other situations that were caused small customizations that I didn't think mattered.
Thank you for looking in to this. I'm sorry if I'm not more help in the problem, but my primary job is with software development.
7
Installation and Upgrades / Re: Zentyal-to-Zentyal tunnel connecting 2 LAN's
« on: April 16, 2013, 12:31:22 am »
Glad I could help, Sam Graf.
I'm looking at two copies of the documentation, both with and without the section you quoted Christian. The first few times I opened the page, it cut off before the section on "Configuration of a VPN server for interconnecting networks", but I'm looking at it now. I'm pretty sure the two hosts are behaving just like you said in the quote. I'm able to give each Zentyal Server secure remote access to a remote LAN. However, "The goal is to connect multiple offices, their Zentyal servers and their internal networks so that one, single network infrastructure can be created in a secure way and through Internet." The documentation in version 2.2 stated: "The goal is to connect the client 1 on the LAN 1 with client 2 on the LAN 2 as if they were in the same local network." Their instructions are rather similar
Using the networking image from the 2.2 documentation to help explain my situation:
Client 1 can connect to any service on LAN 1, ZENTYAL OpenVPN Server, or ZENTYAL OpenVPN Client (via the Zentyal-to-Zentyal VPN IP address), but client 1 cannot connect to client 2.
Client 2 can connect to any service on LAN 2, ZENTYAL OpenVPN Client, or ZENTYAL OpenVPN Server (via the Zentyal-to-Zentyal VPN IP address), but client 2 cannot connect to client 1.
ZENTYAL OpenVPN Server and Client can both access anything pictured.
I have the proper LAN advertised by the OpenVPN server, and I updated the configuration in my first post to reflect that. I can also apply extra hooks into Zentyal that fixes the problem for either client 1 or client 2, but not for both at the same time (probably my lack of knowledge). However, it sounds like this should be done automatically. Left alone, the VPN doesn't connect client 1 to client 2.
Am I misunderstanding the Zentyal-to-Zentyal tunnel? Are only the Zentyal machines supposed to see both clients, and the two client computers (client 1 & client 2) not talk to each other? I had to manually reconfigure the Zentyal 2.2 machine to push DHCP options for DNS and domain (via a customized copy of openvpn.conf.mas in /etc/zentyal/stubs/openvpn/openvpn.conf.mas), which I seem to only be able to apply to all VPN's, but that shouldn't affect anything, especially since I'm using IP addresses for testing. Could my problem be a bug in Zentyal 2.2, where I should upgrade ASAP and ignore the problem until then?
I'm looking at two copies of the documentation, both with and without the section you quoted Christian. The first few times I opened the page, it cut off before the section on "Configuration of a VPN server for interconnecting networks", but I'm looking at it now. I'm pretty sure the two hosts are behaving just like you said in the quote. I'm able to give each Zentyal Server secure remote access to a remote LAN. However, "The goal is to connect multiple offices, their Zentyal servers and their internal networks so that one, single network infrastructure can be created in a secure way and through Internet." The documentation in version 2.2 stated: "The goal is to connect the client 1 on the LAN 1 with client 2 on the LAN 2 as if they were in the same local network." Their instructions are rather similar
Using the networking image from the 2.2 documentation to help explain my situation:
Client 1 can connect to any service on LAN 1, ZENTYAL OpenVPN Server, or ZENTYAL OpenVPN Client (via the Zentyal-to-Zentyal VPN IP address), but client 1 cannot connect to client 2.
Client 2 can connect to any service on LAN 2, ZENTYAL OpenVPN Client, or ZENTYAL OpenVPN Server (via the Zentyal-to-Zentyal VPN IP address), but client 2 cannot connect to client 1.
ZENTYAL OpenVPN Server and Client can both access anything pictured.
I have the proper LAN advertised by the OpenVPN server, and I updated the configuration in my first post to reflect that. I can also apply extra hooks into Zentyal that fixes the problem for either client 1 or client 2, but not for both at the same time (probably my lack of knowledge). However, it sounds like this should be done automatically. Left alone, the VPN doesn't connect client 1 to client 2.
Am I misunderstanding the Zentyal-to-Zentyal tunnel? Are only the Zentyal machines supposed to see both clients, and the two client computers (client 1 & client 2) not talk to each other? I had to manually reconfigure the Zentyal 2.2 machine to push DHCP options for DNS and domain (via a customized copy of openvpn.conf.mas in /etc/zentyal/stubs/openvpn/openvpn.conf.mas), which I seem to only be able to apply to all VPN's, but that shouldn't affect anything, especially since I'm using IP addresses for testing. Could my problem be a bug in Zentyal 2.2, where I should upgrade ASAP and ignore the problem until then?
8
Installation and Upgrades / Re: Zentyal-to-Zentyal tunnel connecting 2 LAN's
« on: April 15, 2013, 06:01:20 pm »
I have servers at our data center that I need to access from the development office. I also have servers at the development office that need to be accessible from the data center, though not quite as urgent. It would also be nice if, at some later point (should we grow), a second development office could be added to the mix, where everyone can see each other. Enabling this would allow any server or workstation to run a service that is listening for a remote connection from any location for things like file transfers, syncing mostly read-only databases, git pushes/pulls, etc.. It may not be the most professional, enterprise setup, but with a small, trusted development group and slow upload speeds at remote offices, it seems an easy and reliable way to keep everything up to date, including a live demo of our development efforts.
The data center, acting as host, has its network listed as advertised, client-to-client connections are on, Zentyal-toZentyal tunnels are on, and I've tried both settings for NAT. The client does not have any configuration that I can find for advertising a network. Once the tunnel is running, the two Zentyal servers could connect to anything on the remote LAN, without any hooks, but as for the other servers and workstations, they could only talk to their own LAN and addresses on the VPN (the remote and local Zentyal servers). I can only see a limited use for this configuration, and I cannot imagine that this was the intended purpose of a Zentyal-to-Zentyal VPN.
I was expecting to run a standard VPN server on both Zentyal machines and making each of them a client for the other VPN. I think I even untarred a standard Linux client bundle on the office router, without it being noticed by Zentyal's OpenVPN. Seeing an option for a Zentyal-to-Zentyal tunnel, my expectation is it would make the two networks operate like connected peers (i.e. automatically route/NAT traffic between them).
The data center, acting as host, has its network listed as advertised, client-to-client connections are on, Zentyal-toZentyal tunnels are on, and I've tried both settings for NAT. The client does not have any configuration that I can find for advertising a network. Once the tunnel is running, the two Zentyal servers could connect to anything on the remote LAN, without any hooks, but as for the other servers and workstations, they could only talk to their own LAN and addresses on the VPN (the remote and local Zentyal servers). I can only see a limited use for this configuration, and I cannot imagine that this was the intended purpose of a Zentyal-to-Zentyal VPN.
I was expecting to run a standard VPN server on both Zentyal machines and making each of them a client for the other VPN. I think I even untarred a standard Linux client bundle on the office router, without it being noticed by Zentyal's OpenVPN. Seeing an option for a Zentyal-to-Zentyal tunnel, my expectation is it would make the two networks operate like connected peers (i.e. automatically route/NAT traffic between them).
9
Installation and Upgrades / Zentyal-to-Zentyal tunnel connecting 2 LAN's
« on: April 13, 2013, 11:55:52 pm »
I'm trying to run a Zentyal-to-Zentyal tunnel that will connect two different LAN's, where both Zentyal servers (v3.0 & v2.2) are acting as routers. The tunnel is up and running, and the Zentyal servers can talk to each other just fine. However, they do not route the LAN traffic across the tunnel. The Zentyal server running v2.2 is at our data center, and hosting the VPN. The v3.0 server is at a software development office, and runs a client. I can only get it half-way working.
Server 1 (data center - Zentyal 2.2)
LAN IP: 192.168.1.1
VPN IP: 192.168.250.1
Advertised network: 192.168.1.0/24
Server 2 (dev office - Zentyal 3.0)
LAN IP: 192.168.2.1
VPN IP: 192.168.250.2
I've added the code to the firewall.postservice hook on each of the services.
The 192.168.1.x network can ping anything on the 192.168.2.x network, including Server 2's ip address for another VPN (192.168.122.1). Server 2 can ping anything on the 192.168.1.x network. Anything on the 192.168.2.x network can ping 192.168.250.1, but not the 192.168.1.x network. If I disable the rule on Server 1 and reboot the server, then computers on 192.168.2.x can ping servers on the 192.168.1.x network, but it obviously disables the 192.168.1.x network pinging servers on the 192.168.2.x network, except I think Server 1 itself can ping 192.168.2.x. Just deleting the rule or restarting the firewall doesn't seem to work. I think restarting the VPN on Server 1 might fix it, once the rule is removed, but I don't remember. I'd like to get this sorted out so I can sync a demo and development database.
*updated Server information*
Server 1 (data center - Zentyal 2.2)
LAN IP: 192.168.1.1
VPN IP: 192.168.250.1
Advertised network: 192.168.1.0/24
Server 2 (dev office - Zentyal 3.0)
LAN IP: 192.168.2.1
VPN IP: 192.168.250.2
I've added the code to the firewall.postservice hook on each of the services.
Code: [Select]
iptables -t nat -A POSTROUTING -o <vpn-interface> -j MASQUERADEThe 192.168.1.x network can ping anything on the 192.168.2.x network, including Server 2's ip address for another VPN (192.168.122.1). Server 2 can ping anything on the 192.168.1.x network. Anything on the 192.168.2.x network can ping 192.168.250.1, but not the 192.168.1.x network. If I disable the rule on Server 1 and reboot the server, then computers on 192.168.2.x can ping servers on the 192.168.1.x network, but it obviously disables the 192.168.1.x network pinging servers on the 192.168.2.x network, except I think Server 1 itself can ping 192.168.2.x. Just deleting the rule or restarting the firewall doesn't seem to work. I think restarting the VPN on Server 1 might fix it, once the rule is removed, but I don't remember. I'd like to get this sorted out so I can sync a demo and development database.
*updated Server information*
10
Installation and Upgrades / CA Certificate still 1024-bit?
« on: April 03, 2013, 12:54:56 am »
Am I looking at (or doing) something wrong, or is the CA Certificate still 1024-bit in Zentyal 3.0?
I posted something about this being a security issue with version 2.2, and was told the size was being increased with the next version. I patched the CA.pm file (/usr/share/perl5/EBox/CA.pm) with a single line of code (between 2070 and 2071), and it's now generating all rsa-4096 certificates (until the file reverts). If it really is still 1024-bit, It would be nice if some fix would make it into the official code and get rolled out with the next update of the web-ui.
I forget how to generate an actual patch. This should be close enough for a human, but if someone wants it, I'll do the work for a real patch file.
I posted something about this being a security issue with version 2.2, and was told the size was being increased with the next version. I patched the CA.pm file (/usr/share/perl5/EBox/CA.pm) with a single line of code (between 2070 and 2071), and it's now generating all rsa-4096 certificates (until the file reverts). If it really is still 1024-bit, It would be nice if some fix would make it into the official code and get rolled out with the next update of the web-ui.
I forget how to generate an actual patch. This should be close enough for a human, but if someone wants it, I'll do the work for a real patch file.
Code: [Select]
$cmd .= qq{-keyout '$args{privKey}' };
+ $cmd .= ' -newkey rsa:4096 ';
if (defined($args{keyPassword})) {
11
Installation and Upgrades / Re: Help Configuring IPsec
« on: February 14, 2013, 09:15:49 pm »
bump
12
Installation and Upgrades / Help Configuring IPsec
« on: November 20, 2012, 01:55:12 am »
I have a production server running Zentyal 2.2 (server #1) in our data center, and a development system running Zentyal 3.0 (server #2) at home, both of them acting as routers connected to the Internet. I'm trying to connect the two LAN segments with IPsec, but I can't get the two to properly connect. I can't find a good Zentyal IPsec tutorial anywhere, so I've changed my IP addresses into something that would hopefully make a good tutorial (and show up on Google searches for years).
Server #1
Server #2
Here is my current, broken configuration. If this configuration looks a bit odd (or impossible), I've tried so many variations that at one point I actually disabled some of the form checking built into Zentyal 3.0, and no longer remember what I've done.
Server #1 General Configuration
Server #2 General Configuration
Server #1 & #2 Authentication Configuration (identical)
Last log entry for VPN on Server #1:
Last log entries for VPN on Server #2:
I'm not sure what is wrong. Any advice? I don't want to switch to using 15 different OpenVPN connections, mostly inside of overcrowded virtual machines, but at least I can make that work. IPsec looks like it should be fairly simple to configure, but this is my second failed attempt. Would the fact that I'm running DHCP on my WAN interface for Server #2 be a problem? It only changes every few months or longer, and I won't mind updating the config.
Server #1
Code: [Select]
Public IP: 1.1.1.1
LAN Subnet: 10.1.1.0/24
Lan IP: 10.1.1.1Server #2
Code: [Select]
Public IP: 2.2.2.2
LAN Subnet: 10.2.2.0/26
Lan IP: 10.2.2.1Here is my current, broken configuration. If this configuration looks a bit odd (or impossible), I've tried so many variations that at one point I actually disabled some of the form checking built into Zentyal 3.0, and no longer remember what I've done.
Server #1 General Configuration
Code: [Select]
Local IP Address: 1.1.1.1
Local Subnet 10.1.1.0/24
Remote IP Address: 2.2.2.2
Remote Subnet: 10.2.2.0/26
PSK Shared Secret: mypasswordServer #2 General Configuration
Code: [Select]
Local IP Address: 2.2.2.2
Local Subnet 10.2.2.0/26
Remote IP Address: 1.1.1.1
Remote Subnet: 10.1.1.0/24
PSK Shared Secret: mypasswordServer #1 & #2 Authentication Configuration (identical)
Code: [Select]
Phase 1
IKE Encryption: AES-256
IKE Authentication: SHA-1
IKE Keylife: 28800
Phase 2
ESP Encryption: AES-256
ESP Authentication: SHA-1
ESP DH Group: 14
ESP Keylife: 3600
Enable PFS: checkedLast log entry for VPN on Server #1:
Code: [Select]
#6: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0xc343bce8 <0x169a9575 xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=none}Last log entries for VPN on Server #2:
Code: [Select]
#2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x169a9575 <0xc343bce8 xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=none}
#1: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x1bcd7f84) not found (maybe expired)
#1: received and ignored informational messageI'm not sure what is wrong. Any advice? I don't want to switch to using 15 different OpenVPN connections, mostly inside of overcrowded virtual machines, but at least I can make that work. IPsec looks like it should be fairly simple to configure, but this is my second failed attempt. Would the fact that I'm running DHCP on my WAN interface for Server #2 be a problem? It only changes every few months or longer, and I won't mind updating the config.
13
Installation and Upgrades / Re: Custom OpenVPN Configuration
« on: March 23, 2012, 04:49:47 pm »
Thank you, that should do it. 
I now have no reason to futilely look for alternatives, especially with all the brillant changes in 3.0 (including a "fast as lightning" UI). 
I now have no reason to futilely look for alternatives, especially with all the brillant changes in 3.0 (including a "fast as lightning" UI).
14
Installation and Upgrades / Custom OpenVPN Configuration
« on: March 23, 2012, 04:52:42 am »
I'm trying to add some custom lines of configuration and a couple of line edits to my OpenVPN configuration file on the server, but every time I restart the OpenVPN service ("/etc/init.d/zentyal openvpn restart" or system reboot), it overwrites my custom configuration. I could go through the code, and after a lot of reading and searching, disable the code that is overwriting my configuration. However, those changes are likely to be undone by a system update, leaving me where I was before, except with second level of changes being overwritten less often. Overwriting config files seems to be terribly wrong behavior for a service restart, especially if the permissions on the file are "-r--------".
Is there any way I can fix this problem of zentyal breaking my configuration? I thought I once saw an option that I turned off for zentyal overwriting config files, but I can't find it anymore. Should I just be spending forever rolling my own services from Ubuntu Server? I like zentyal except for a few places where I'm not given enough options (e.g. setting the numeric uid or gid requires LDAP separate software), the security currently being a little weak, and the interface is kinda slow (but faster than looking up howtos for everything).
Is there any way I can fix this problem of zentyal breaking my configuration? I thought I once saw an option that I turned off for zentyal overwriting config files, but I can't find it anymore. Should I just be spending forever rolling my own services from Ubuntu Server? I like zentyal except for a few places where I'm not given enough options (e.g. setting the numeric uid or gid requires LDAP separate software), the security currently being a little weak, and the interface is kinda slow (but faster than looking up howtos for everything).
15
Installation and Upgrades / Reset LDAP database
« on: December 20, 2011, 07:05:57 am »
Is there any way to reset the LDAP database? I have moved the server from a development site to put it into production. I would just edit everything, but the base DN isn't correct for the new location. I've tried correcting the root DN by using JXplorer to export everything to an LDIF file that has a new root DN, but I get an error when importing.
There isn't much worthwhile stored in the LDAP database, so I figured resetting it would be the easiest and cleanest thing to do, if I can find out how. Removing and re-installing the module doesn't affect the LDAP database. If I go in with an LDAP browser like JXplorer or Apache Directory Studio and delete everything, will that trigger zentyal to rebuild the default database? Will that also fix the files under /etc/ that store the old base DN?
There isn't much worthwhile stored in the LDAP database, so I figured resetting it would be the easiest and cleanest thing to do, if I can find out how. Removing and re-installing the module doesn't affect the LDAP database. If I go in with an LDAP browser like JXplorer or Apache Directory Studio and delete everything, will that trigger zentyal to rebuild the default database? Will that also fix the files under /etc/ that store the old base DN?
Pages: [1] 2