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]
1
Email and Groupware / Re: migrate emails from Zentyal 3.2 to 3.5
« on: December 19, 2015, 04:53:24 am »
I saw no difference in the directory structure. Made a tar of each user from /var/vmail/domainname.com/ in Zentyal 3.2.
When I went to the same folder in Zentyal 3.5, I saw the new user names I had created, so untarred over them.
/etc/postfix/main.cf has many references to aliases, and several ldap: specs. So, it seems reasonable that both Zentyal versions are using ldap to do the lookups, but I didn't know how to bring the postfix ldap info from the old server.
Thanks
When I went to the same folder in Zentyal 3.5, I saw the new user names I had created, so untarred over them.
/etc/postfix/main.cf has many references to aliases, and several ldap: specs. So, it seems reasonable that both Zentyal versions are using ldap to do the lookups, but I didn't know how to bring the postfix ldap info from the old server.
Thanks
2
Email and Groupware / migrate emails from Zentyal 3.2 to 3.5
« on: December 18, 2015, 05:28:10 pm »
The Zentyal 3.2 server became unusable, with many segfaults during startup. Moving mail from old server to new didn't work, and my searches here and elsewhere didn't help, but someone has surely solved this problem.
Created fresh install of Zentyal 3.5, recreated three email users, saw their entries in /var/vmail/ folder
Tarred folders on old server, untarred on new server, saw that permissions were retained ( all owned by ebox:ebox)
NONE of the emails show in webmail when testing.
Could this be the problem: "Postfix now binds to LDAP" from 3.2 feature list.
If so, how would anyone move emails from an unbootable server???
Can I have postfix reload all the mail? Command "postfix reload" simply re-reads the config files, apparently
Can I transfer the postfix part of LDAP from old server to new?
Thanks!
Created fresh install of Zentyal 3.5, recreated three email users, saw their entries in /var/vmail/ folder
Tarred folders on old server, untarred on new server, saw that permissions were retained ( all owned by ebox:ebox)
NONE of the emails show in webmail when testing.
Could this be the problem: "Postfix now binds to LDAP" from 3.2 feature list.
If so, how would anyone move emails from an unbootable server???
Can I have postfix reload all the mail? Command "postfix reload" simply re-reads the config files, apparently
Can I transfer the postfix part of LDAP from old server to new?
Thanks!
3
Installation and Upgrades / Can't start slapd after upgrading zentyal-* packages
« on: May 23, 2014, 04:58:20 pm »
Zentyal had been working fine as a mail server, though the web interface was unavailable after some updates.
Yesterday, I saw over 100 upgrades waiting so applied all the apache2 updates, and the web interface worked again!
THEN I applied all the zentyal-* updates and it brought the mail service down for a long time. Someone in the office sensed a problem and powered the machine OFF while update was running!
I've been able to use "sudo dpkg --configure <pkg>" to eventually complete all unconfigured or half-configured packages except zentyal-samba, which eventually says "FATAL: Couldn't connect to LDAP server".
Actually LDAP is not running, and when I try to start it it complains there is no pid specified. When I specify pid in /etc/default/slapd, in the standard location, it says "Starting OpenLDAP slapd" [fail]
Comparing /etc/ldap/slapd.d/ to a working system, it may have been reset, as cn=config.ldif is empty.
Help!
Yesterday, I saw over 100 upgrades waiting so applied all the apache2 updates, and the web interface worked again!
THEN I applied all the zentyal-* updates and it brought the mail service down for a long time. Someone in the office sensed a problem and powered the machine OFF while update was running!
I've been able to use "sudo dpkg --configure <pkg>" to eventually complete all unconfigured or half-configured packages except zentyal-samba, which eventually says "FATAL: Couldn't connect to LDAP server".
Actually LDAP is not running, and when I try to start it it complains there is no pid specified. When I specify pid in /etc/default/slapd, in the standard location, it says "Starting OpenLDAP slapd" [fail]
Comparing /etc/ldap/slapd.d/ to a working system, it may have been reset, as cn=config.ldif is empty.
Help!
4
Installation and Upgrades / Re: Access Database "network access" errors on share
« on: July 31, 2012, 03:12:08 pm »
Moderator:
The other thread has been solved, but this Access database error lingers on. The problem will appear to be gone for hours, but they've never gotten through a day with multiple users, WinXP and Win7, getting networking errors at some point. They claim that it happened when only one user was using Win7, but I'm not convinced that no one else was using the database during that time.
I have applied all the smb.conf adjustments that I've found relevant in searches, and verified that the smb.conf file is keeping the changes after adding a new user or changing ACLs, so the solution from the other thread is working.
Any further suggestions would be very much appreciated, as all was working well on the previous server running plain Ubuntu Server.
The other thread has been solved, but this Access database error lingers on. The problem will appear to be gone for hours, but they've never gotten through a day with multiple users, WinXP and Win7, getting networking errors at some point. They claim that it happened when only one user was using Win7, but I'm not convinced that no one else was using the database during that time.
I have applied all the smb.conf adjustments that I've found relevant in searches, and verified that the smb.conf file is keeping the changes after adding a new user or changing ACLs, so the solution from the other thread is working.
Any further suggestions would be very much appreciated, as all was working well on the previous server running plain Ubuntu Server.
5
Installation and Upgrades / Re: Access Database "network access" errors on share
« on: July 21, 2012, 03:01:45 am »
UPDATE: These updates to the smb.conf, applied to the share in question:
oplocks = no
level2 oplocks = no
force group = datausers
force create mode = 0770
force directory mode = 0770
appear to have fixed the problem, but they were lost when I added a another user to the share. Thanks to a helpful response on my other posting about "smb.conf", I believe the problem will prove to be solved on Monday, since I edited /usr/share/zentyal/stubs/samba/smb.conf.mas to add the first 3 lines and change the mode of the other two lines.
Will gladly close this topic if Monday proves to be uneventful...
oplocks = no
level2 oplocks = no
force group = datausers
force create mode = 0770
force directory mode = 0770
appear to have fixed the problem, but they were lost when I added a another user to the share. Thanks to a helpful response on my other posting about "smb.conf", I believe the problem will prove to be solved on Monday, since I edited /usr/share/zentyal/stubs/samba/smb.conf.mas to add the first 3 lines and change the mode of the other two lines.
Will gladly close this topic if Monday proves to be uneventful...
6
Installation and Upgrades / Re: Preserving tweaks to smb.conf -- WHO clobbered them?
« on: July 21, 2012, 01:54:31 am »
Christian:
Yes! That's the explanation that I was looking for. I've edited the .mas file and added a user to a share, then a diff of the old and new file shows my customization intact. Happy Day.
Tom
Yes! That's the explanation that I was looking for. I've edited the .mas file and added a user to a share, then a diff of the old and new file shows my customization intact. Happy Day.
Tom
7
Installation and Upgrades / [Solved] Preserving tweaks to smb.conf -- WHO clobbered them?
« on: July 20, 2012, 10:31:34 pm »
Yesterday I seemed to have solved the networking problem, causing users of an Access database to lose their connection. What I think fixed it was adding to the share in smb.conf:
oplocks = no
level2 oplocks = no
force group = datausers
force create mode = 0770
force directory mode = 0770
and today when the problem had returned, I found BOTH oplocks lines and the force group line GONE, and both 0770 replaced by 0660. What I think may have done that is creating another share in the Zentyal interface, causing smb.conf to be rewritten.
IF TRUE, I need a way to preserve those tweaks. IF NOT TRUE, then who changed them? Must I learn the cryptic language of ldap or what?
Tom
oplocks = no
level2 oplocks = no
force group = datausers
force create mode = 0770
force directory mode = 0770
and today when the problem had returned, I found BOTH oplocks lines and the force group line GONE, and both 0770 replaced by 0660. What I think may have done that is creating another share in the Zentyal interface, causing smb.conf to be rewritten.
IF TRUE, I need a way to preserve those tweaks. IF NOT TRUE, then who changed them? Must I learn the cryptic language of ldap or what?
Tom
8
Installation and Upgrades / Access Database "network access" errors on share
« on: July 20, 2012, 07:06:06 pm »
Anyone:
I'm getting desperate, as this problem has dragged on for a week, with the users twice saying the problem was fixed, and then it returned the next day.
I set up the v2.2 server with 2 1TB drives in RAID 1, with a single share, and in a folder on that share, put the Access database. The users reported that if they let the custom-written (that worked fine on the previous Ubuntu Server installation) Visual Basic program sit unused for a minute, they got an error like "Run-time error '3043': Your network access was interrupted".
Originally we made the share guest access, and storing files there had no issues -- only the database.
I removed guest access, created an account for each user, gave them all read-write access to the share. It seemed fine for a few hours, but gave errors eventually. Win7 users couldn't copy files to the share, as it said there was no space, until I changed them from read-write to admin, and then file copy was OK again.
I added to the smb.conf file, for this share "oplocks = no" and when that didn't help, "level2 oplocks = no" "force group = datausers" and changed "force create mode" & "force directory mode" to 0770. Again, it passed immediate testing, but later gave variations on "your network access was interrupted".
From my extensive searches for clues, I'm wondering if SELinux could be causing this problem?
Any suggestion would be appreciated!
Tom
I'm getting desperate, as this problem has dragged on for a week, with the users twice saying the problem was fixed, and then it returned the next day.
I set up the v2.2 server with 2 1TB drives in RAID 1, with a single share, and in a folder on that share, put the Access database. The users reported that if they let the custom-written (that worked fine on the previous Ubuntu Server installation) Visual Basic program sit unused for a minute, they got an error like "Run-time error '3043': Your network access was interrupted".
Originally we made the share guest access, and storing files there had no issues -- only the database.
I removed guest access, created an account for each user, gave them all read-write access to the share. It seemed fine for a few hours, but gave errors eventually. Win7 users couldn't copy files to the share, as it said there was no space, until I changed them from read-write to admin, and then file copy was OK again.
I added to the smb.conf file, for this share "oplocks = no" and when that didn't help, "level2 oplocks = no" "force group = datausers" and changed "force create mode" & "force directory mode" to 0770. Again, it passed immediate testing, but later gave variations on "your network access was interrupted".
From my extensive searches for clues, I'm wondering if SELinux could be causing this problem?
Any suggestion would be appreciated!
Tom
9
Installation and Upgrades / Re: lost /boot partition --- how to recover it?
« on: September 11, 2011, 04:59:05 pm »
Wow -- lots of views but no reply.
Well, on Friday (after consulting with a Linux guru associate) I repaired the installation!
Here's what it took:
At working machine, identical to ailing machine execpt for kernel version: sudo cp -a /boot/* /media/flash/BootPartBack
At ailing machine: sudo cp -a /media/flash/BootPartBack/* /boot
sudo apt-get install (same kernel version as working machine), as it was one version behind, which updated grub successfully
sudo tune2fs -l /dev/sdc1 (to get UUID of new boot partition)
sudo vi /etc/fstab (to replace previous UUID with current UUID)
physically replace the failed drive with the new drive (which had been in external USB adapter)
REBOOT, and see the partition was automatically checked for errors, then boot proceeded!
Subsequently, I've copied the contents of /boot to a new folder on the mirrored drives, so it can be restored from there, should the first drive die again. I'll have to remember to refresh that backup after each kernel upgrade. Better techniques are welcomed...
Hope this helps anyone, like me, learning their way around software RAID.
Well, on Friday (after consulting with a Linux guru associate) I repaired the installation!
Here's what it took:
At working machine, identical to ailing machine execpt for kernel version: sudo cp -a /boot/* /media/flash/BootPartBack
At ailing machine: sudo cp -a /media/flash/BootPartBack/* /boot
sudo apt-get install (same kernel version as working machine), as it was one version behind, which updated grub successfully
sudo tune2fs -l /dev/sdc1 (to get UUID of new boot partition)
sudo vi /etc/fstab (to replace previous UUID with current UUID)
physically replace the failed drive with the new drive (which had been in external USB adapter)
REBOOT, and see the partition was automatically checked for errors, then boot proceeded!
Subsequently, I've copied the contents of /boot to a new folder on the mirrored drives, so it can be restored from there, should the first drive die again. I'll have to remember to refresh that backup after each kernel upgrade. Better techniques are welcomed...
Hope this helps anyone, like me, learning their way around software RAID.
10
Installation and Upgrades / lost /boot partition --- how to recover it?
« on: September 01, 2011, 04:49:14 pm »
Problem: drive with boot partition failed completely
I set up mirrored drives for the main installation, but created a /boot partition at the beginning of drive sda, and a swap partition at the beginning of sdb, installing Zentyal 2.0.13, kernel 2.6.32-24-generic x86_64
/dev/sda1 /boot (1 GB)
/dev/sdb1 swap (1 GB)
/dev/md0 (sda5 & sdb5) /
Since drive sda has become totally unreadable, I avoided rebooting while adding an external USB drive, partitioned exactly as the others, failed sda5 and added sdc5 to software RAID (it synced in 4 hours), and mounted sdc1 and installed grub there.
HOWEVER I know the rest of /boot is missing, confirmed by the smaller used space there.
I've booted from usb Zentyal, and can't find a tool to reinstall /boot.
I've got another box built with the same hardware running Zentyal 2.0.22, kernel 2.6.32-26-generic x86_64. WOULD IT BE OK to make a backup of that partition, and copy it into the new /boot partition? Then, I suppose, update grub?
Better idea? I've got to solve this before an extended power outage!
Thanks,
Tom
I set up mirrored drives for the main installation, but created a /boot partition at the beginning of drive sda, and a swap partition at the beginning of sdb, installing Zentyal 2.0.13, kernel 2.6.32-24-generic x86_64
/dev/sda1 /boot (1 GB)
/dev/sdb1 swap (1 GB)
/dev/md0 (sda5 & sdb5) /
Since drive sda has become totally unreadable, I avoided rebooting while adding an external USB drive, partitioned exactly as the others, failed sda5 and added sdc5 to software RAID (it synced in 4 hours), and mounted sdc1 and installed grub there.
HOWEVER I know the rest of /boot is missing, confirmed by the smaller used space there.
I've booted from usb Zentyal, and can't find a tool to reinstall /boot.
I've got another box built with the same hardware running Zentyal 2.0.22, kernel 2.6.32-26-generic x86_64. WOULD IT BE OK to make a backup of that partition, and copy it into the new /boot partition? Then, I suppose, update grub?
Better idea? I've got to solve this before an extended power outage!
Thanks,
Tom
Pages: [1]