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

Pages: [1]
1
I just ran into the same problem,
Users and groups: 3.0.7
File Sharing and Domain Services: 3.0.10

2
Installation and Upgrades / Re: 2.0 to 2.2 - Third-party modules
« on: January 15, 2012, 03:27:00 am »
Thanks, I'm very relieved that this will be much simpler then I feared it was going to be, though I def plan on doing as much testing as I can on this server before migrating. I've migrated 2 servers so far, the first one failed 1/2 way due to some kind of issue with the antivirus module but it was just a simple router box so I started that one in 2.2 from scratch which was probably for the best anyway to clean the firewall rules and services. The second one migrated smoothly without a hitch which I'm extremely grateful for since that one was a data/PDC server that would of sucked to remake. This third one I'm about to migrate is the main server in another location that handles all zentyal modules in addition to a slew of other things critical to my business  :-\

3
Installation and Upgrades / 2.0 to 2.2 - Third-party modules
« on: January 14, 2012, 07:34:33 am »
In the notes for the 2.0 to 2.2 migration tool it says:
Quote
Third-party or unofficial modules

    * If you have any non-official modules installed, you have to purge them before starting the migration process.
    * You'll be able to install them again after the migration process is completed.
Does this include things like a SVN server? One of my Zentyal boxes has a bunch of non zentyal things on it like a SVN server, 2 different render management dispatchers, synergy, openfire jabber server, mumble server, MySQL server, and probably a few others I've forgotten about. If these all need purged prior to the migration, is there some kind of way to get a list of everything that's on there that I've forgotten about to make sure that I get rid of it all? Which would be a good thing to get rid of things I've tried and played with but never ended up using.  Some things like the render dispatch servers and synergy weren't simple "apt-get install" things and needed customization to make them start at boot time (which was so long ago that I forget exactly how I did it and which things needed it). Exporting the zentyal config, reformatting the machine then restoring it before migrating would solve this (would doing this restore things like users for the PDC and/or their profiles?), but things like the SVN and MySQL need to end up in the exact same state they're in currently (which I have no idea how to do that).

Also, the notes say
Quote
We strongly recommend you, if possible, to try this first on a test machine (a VM for example) restoring the configuration backup of your production server, or even better if you can clone an image of the whole disk.

 ??? Could someone point me to somewhere that explains how to do the clone the whole disk thing?

Muchos gracias  ;D

4
Installation and Upgrades / Re: 1.4 slave usersandgroups nasty bug
« on: February 15, 2010, 04:27:50 pm »
In the master > users and groups > slave status I've got a list of pending actions on modifications I've done since I first joined the slave to the master. But the only button is "sync" which flashes a message that says "done" but the pending actions remain.

5
Installation and Upgrades / Re: 1.4 slave usersandgroups nasty bug
« on: February 15, 2010, 01:30:07 pm »
I'm in the exact same situation. Finally got Master/Slave working but now can't make a user an admin of the PDC on the slave. My error code is a little different though:
Code: [Select]
A really nasty bug has occurred
Exception
Unknown error at EBox::UsersAndGroups::addUserToGroup Referral received
Trace
Unknown error at EBox::UsersAndGroups::addUserToGroup Referral received at /usr/share/perl5/EBox/Ldap.pm line 712
EBox::Ldap::_errorOnLdap('Net::LDAP::Modify=HASH(0xb7c3494)', 'HASH(0xb7bdda0)') called at /usr/share/perl5/EBox/Ldap.pm line 373
EBox::Ldap::modify('EBox::Ldap=HASH(0xa2a92a4)', 'cn=Domain Admins,ou=Groups,dc=c2istudios,dc=com', 'HASH(0xb7bdda0)') called at /usr/share/perl5/EBox/UsersAndGroups.pm line 1732
EBox::UsersAndGroups::addUserToGroup('EBox::UsersAndGroups=HASH(0x9fdbefc)', 'ymangolds', 'Domain Admins') called at /usr/share/perl5/EBox/Samba.pm line 844
EBox::Samba::setAdminUser('EBox::Samba=HASH(0xa793e94)', 'ymangolds', 'yes') called at /usr/share/perl5/EBox/CGI/Samba/ActiveSharing.pm line 79
EBox::CGI::Samba::ActiveSharing::_user('EBox::CGI::Samba::ActiveSharing=HASH(0xb7eac5c)') called at /usr/share/perl5/EBox/CGI/Samba/ActiveSharing.pm line 86
EBox::CGI::Samba::ActiveSharing::_process('EBox::CGI::Samba::ActiveSharing=HASH(0xb7eac5c)') called at /usr/share/perl5/EBox/CGI/Base.pm line 262
EBox::CGI::Base::run('EBox::CGI::Samba::ActiveSharing=HASH(0xb7eac5c)') called at /usr/share/perl5/EBox/CGI/Run.pm line 120
EBox::CGI::Run::run('EBox::CGI::Run', 'Samba/ActiveSharing', 'EBox') called at /usr/share/ebox/cgi/ebox.cgi line 19
ModPerl::ROOT::ModPerl::Registry::usr_share_ebox_cgi_ebox_2ecgi::handler('Apache2::RequestRec=SCALAR(0xb70c034)') called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 204
eval {...} called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 204
ModPerl::RegistryCooker::run('ModPerl::Registry=HASH(0xb791a34)') called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 170
ModPerl::RegistryCooker::default_handler('ModPerl::Registry=HASH(0xb791a34)') called at /usr/lib/perl5/ModPerl/Registry.pm line 31
ModPerl::Registry::handler('ModPerl::Registry', 'Apache2::RequestRec=SCALAR(0xb70c034)') called at -e line 0
eval {...} called at -e line 0

6
I have the same situation but a slightly different error
Code: [Select]
A really nasty bug has occurred
Exception
Failed to enable: Can't call method "get_value" on an undefined value at /usr/share/perl5/EBox/UsersAndGroups.pm line 2590.
Trace
Failed to enable: Can't call method "get_value" on an undefined value at /usr/share/perl5/EBox/UsersAndGroups.pm line 2590.
at /usr/share/perl5/EBox/CGI/ServiceModule/ConfigureModuleController.pm line 74
EBox::CGI::ServiceModule::ConfigureModuleController::_process('EBox::CGI::ServiceModule::ConfigureModuleController=HASH(0x8f...') called at /usr/share/perl5/EBox/CGI/Base.pm line 262
EBox::CGI::Base::run('EBox::CGI::ServiceModule::ConfigureModuleController=HASH(0x8f...') called at /usr/share/perl5/EBox/CGI/Run.pm line 120
EBox::CGI::Run::run('EBox::CGI::Run', 'ServiceModule/ConfigureModuleController', 'EBox') called at /usr/share/ebox/cgi/ebox.cgi line 19
ModPerl::ROOT::ModPerl::Registry::usr_share_ebox_cgi_ebox_2ecgi::handler('Apache2::RequestRec=SCALAR(0x9019f78)') called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 204
eval {...} called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 204
ModPerl::RegistryCooker::run('ModPerl::Registry=HASH(0x9019b28)') called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 170
ModPerl::RegistryCooker::default_handler('ModPerl::Registry=HASH(0x9019b28)') called at /usr/lib/perl5/ModPerl/Registry.pm line 31
ModPerl::Registry::handler('ModPerl::Registry', 'Apache2::RequestRec=SCALAR(0x9019f78)') called at -e line 0
eval {...} called at -e line 0

Is there any estimate on when having a PDC on the same machine as the master will be available? I recently bought a new file server and upgraded my old one to 1.4 (which currently has the PDC). Is there a way to transfer the PDC over to the new fileserver (recreating it from scratch may cause problems with things like MS project server)?

Also, will disabling the things requiring users and groups be enough to have it be the master LDAP, or will i need a complete reinstall?

BTW, eBox is by far the best thing to happen to my IT dept (which consists of me, and I'm not an IT guru) and has made life much more enjoyable. Awesome work guys  ;D.

7
Installation and Upgrades / VPN, UDP, and DMZ
« on: September 12, 2009, 10:15:26 pm »
Here's my network seup:

                     Cable Modem
                             |
                             |
              Linksys WRT54GS Router
                      IP:10.0.0.1
                  DMZ:10.0.0.254
                             |
                             |
                         Ebox
             External NIC:10.0.0.254
               Internal NIC1:10.10.2.1
               Internal NIC2:10.5.1.1
              VPN network:10.10.5.x
                   /                   \
                  /                     \
     Switch for LAN           Wireless router
                                     (different then the one between the ebox and the modem)

We've more or less gotten VPN to work using TCP 1194 but it's too slow to do the things we need it for.

After reading this post: http://forum.ebox-platform.com/index.php?topic=675.0 I tried recreating the VPN server using UDP 1194. But when remote clients try to connect they get this:

Code: [Select]
Sun Sep 06 15:22:54 2009 OpenVPN 2.1_rc15 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Nov 19 2008
Sun Sep 06 15:22:54 2009 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Sun Sep 06 15:22:54 2009 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sun Sep 06 15:22:54 2009 LZO compression initialized
Sun Sep 06 15:22:54 2009 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun Sep 06 15:22:54 2009 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Sep 06 15:22:54 2009 Local Options hash (VER=V4): 'd79ca330'
Sun Sep 06 15:22:54 2009 Expected Remote Options hash (VER=V4): 'f7df56b8'
Sun Sep 06 15:22:54 2009 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sun Sep 06 15:22:54 2009 UDPv4 link local: [undef]
Sun Sep 06 15:22:54 2009 UDPv4 link remote: XX.XXX.XXX.XXX:1194
Sun Sep 06 15:22:55 2009 TCP/UDP: Incoming packet rejected from XX.XXX.XXX.XXX:1024[2], expected peer address: XX.XXX.XXX.XXX:1194 (allow this incoming source address/port by removing --remote or adding --float)
Sun Sep 06 15:22:56 2009 TCP/UDP: Incoming packet rejected from XX.XXX.XXX.XXX:1024[2], expected peer address: XX.XXX.XXX.XXX:1194 (allow this incoming source address/port by removing --remote or adding --float)
Sun Sep 06 15:22:57 2009 TCP/UDP: Incoming packet rejected from XX.XXX.XXX.XXX:1024[2], expected peer address: XX.XXX.XXX.XXX:1194 (allow this incoming source address/port by removing --remote or adding --float)
Sun Sep 06 15:22:58 2009 TCP/UDP: Incoming packet rejected from XX.XXX.XXX.XXX:1024[2], expected peer address: XX.XXX.XXX.XXX:1194 (allow this incoming source address/port by removing --remote or adding --float)

The last line continues to loop...

I tried adding "float" to the client's config file and it appears to work, except that it reconnects every 5 minutes interrupting whatever the user was doing over the vpn.
I also tried putting the client on a computer that's part of the internal LAN and everything worked fine, which leads me to believe that the router with DMZ set to the ebox is culprit. So I'm assuming that it should work fine if the ebox can be used as the router but after reading http://forum.ebox-platform.com/index.php?topic=33.0 I'm guessing that's not possible.

I've also tried adding port forwarding on 1194 to 10.0.0.254 on the router but with no luck.

Any ideas?

8
Installation and Upgrades / Re: Ebox LDAP Configuration (OpenFire)
« on: June 30, 2009, 01:59:39 am »
Biggest reason we use openfire is the group push and auto-join conference/bookmarks features. We started out using Jabberd2 (this is long before we started using ebox) but switched to openfire when a friend told me about it's features.

Group push auto pushes buddy lists to groups specified, which is a really nice feature for teams since when a new member is added to a team everyone automatically has them added to their buddy list.

Auto-join conferences is essential for us since conference chat is our primary method of comunication/organizing projects. It makes people join premade conference rooms specified and limits the amount of 1 on 1 chat. It also populates the chat client's (we use Spark, made by the same guys who make openfire) bookmarks with ones we specify so people have the same lists of web bookmarks and get updated auto when we need to change them.

Other features that are really usefully (not sure if they're available/will work in Jabberd2) are:
IM gateway/protocol translation, so people can register their MSN, Yahoo, Gtalk, irc, etc accounts and use them all in the same place.
SparkWeb which is a web based client people can log into and use from anywhere if they're away from their workstation.
Whiteboarding and code collaborating via plugins for the Spark client
Fast Path which allows for "tech-support" style queing for clients via a web interface
Asterisk and SIP phone integration

9
Installation and Upgrades / Re: Ebox LDAP Configuration (OpenFire)
« on: June 27, 2009, 09:23:28 am »
I'm in the exact same situation. What settings did you find to work the best?

I found these to kindof work, but users get kicked from conferences sometimes and status' don't always update properly.




Pages: [1]