Login to Your Zimbra Server with root login and password .
Type following commands :-
[[email protected]]# su – zimbra
This Command will change the Console name to
[[email protected] ~]$
Then Type Following command.
[[email protected] ~]$ zmprov -l renamedomain olddomain.com newdomain.com
This has been tested against Zimbra 6, 7 and 8.
To reset the administrative password:
su – zimbra
To get a list of all administrators:
su – zimbra
To access the admin console:
Remember that the administrative console (sometimes) requires a full email address as the login name, so you may be using the correct password and the wrong login!
CSF has been one of the first choice for years now for me to secure server with a easily usable iptables manager. More than that it works as “A Stateful Packet Inspection (SPI) firewall, Login/Intrusion Detection and Security application for Linux servers”.
While using csf on OpenVZ vps systems we end up facing lots of issues with respect to iptables modules. If you’re a sysadmin managing hardware nodes it might not be easy though it has got to do something quite simple. I’m pasting the similar issue once again here for a reference and let us recheck what we normally oversee.
Error received during csf test:
Testing ipt_recent…FAILED [Error: iptables: No chain/target/match by that name.] – Required for PORTFLOOD and PORTKNOCKING features
Testing xt_connlimit…FAILED [Error: iptables: No chain/target/match by that name.] – Required for CONNLIMIT feature
Testing ipt_owner/xt_owner…FAILED [Error: iptables: No chain/target/match by that name.] – Required for SMTP_BLOCK and UID/GID blocking features
RESULT: csf will function on this server but some features will not work due to some missing iptable modules
Now, the quick remedy that we get to resolve this issue is to enable all the iptable modules in /etc/vz/vz.conf of the OpenVZ hardware node as follows:
IPTABLES=”ip_tables iptable_filter iptable_mangle ipt_limit ipt_multiport ipt_tos ipt_TOS ipt_REJECT ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_LOG ipt_length ip_conntrack ip_conntrack_ftp ipt_state iptable_nat ip_nat_ftp ipt_recent ipt_owner ipt_conntrack ipt_helper ipt_REDIRECT ipt_recent ipt_owner”
and restart all VM’s etc using “service vz restart” to activate all modules to all VPS systems.
The other options we have is to enable these modules for a specific VPS/VM as follows: (PS: here 100 is a VPS id)
vzctl set 100 –iptables ipt_REJECT –iptables ipt_tos –iptables ipt_TOS –iptables ipt_LOG –iptables ip_conntrack –iptables ipt_limit –iptables ipt_multiport –iptables iptable_filter –iptables iptable_mangle –iptables ipt_TCPMSS –iptables ipt_tcpmss –iptables ipt_ttl –iptables ipt_length –iptables ipt_state –iptables iptable_nat –iptables ip_nat_ftp –iptables ipt_owner –iptables ipt_recent –save
If you run the above command with –setmode option, the modules will be applied.
Or you can add the IPTABLES line mentioned earlier (vz.conf entry) to VPS configuration file (/etc/vz/conf/100.conf for the above example VPS) and restart VPS with the following command to make it effective.
vzctl restart 100
This was quite simple and known answer. But I have always found that it doesn’t go so smooth. This might be because of one simple reason that I quote here:
We keep removing OLD kernel packages etc and install the new ones to ensure that we have secure system with latest kernel and packages. During this process we end up loosing kernel modules required for the new modules. I figure this out once again while working on my hardware node just by typing the find command as follows under /lib
find /lib –name *ipt*
I was expecting the iptables modules to be listed under my current kernel but to my surprise I didn’t find them. I found them in one of the very old kernel that was installed on the box. Crazy. So, I decided to jump in and reinstall iptables packages quickly on the machine:
yum reinstall iptables-devel.i686 iptables-devel.x86_64 iptables-ipv6.x86_64 iptables.i686 iptables.x86_64
Here is the final output of my csf test after restarting my VM.
RESULT: csf should function on this server
That’s it. Now you know why iptables doesn’t work even if you had not changed anything recently on hardware node (and forgotten that you restarted your system with a new kernel). Verify the iptables modules with lsmod and reinstall the packages if required.
You might get to see the above error while booting your VM’s on VMWare Workstation 9.x on Ubuntu.
This issue might get sorted by adding the following line to .vmx line of the VM.
mks.gl.allowBlacklistedDrivers = TRUE
Read the further discussion on this topic at vmware forum.
Due to power failure if your Citrix Xen Slave server doesn’t get back online in pool, this might help:
When the Xen environment changes the pool master, If a slave cannot reach the pool master it goes into a failed state. To change this edit pool.conf file (vi /etc/xensource/pool.conf) and changed the pool master IP address from 10.174.XX.XX to 10.174.XX.YY (to the correct new pool master address). The following identifies the changes as represented within the .conf file:
Once the change is complete, run xe-toolstack-restart. The management interfaces should be restarted and as a precaution the server restart should help. On reboot, you will be able to see the slave server joining the pool without any trouble.
Use the following command to copy the partition table from sda to sdb.
sfdisk -d /dev/sda | sfdisk -f /dev/sdb
sfdisk -d dumps the partition table on to stdout. This is being piped to sfdisk /dev/sdb with the –force to write it on /dev/sdb.
You can use dd to copy the Master Boot Record (MBR) from one device to another (or to a file). For example, copying the MBR from sda to sdb would be done with
dd if=/dev/sda of=/dev/sdb bs=512 count=1
The flags are
if, input file (either device or ordinary file)
of, output file (either device or ordinary file)
bs, block size in bytes
count, number of blocks to copy.
The MBR contains the partition table for the four primary partitions, so this solution alone will not copy the definition for the extended partitions.
If you’re getting Internal server error all over the places on your websites on a cPanel server and PHP is configured to run as suphp CGI mode, then you might be observing the following error on error_log due to ModSecurity. It might be searching for the sticky/suid permission on suphp binary:
SecurityException in Application.cpp:188: Do not have root privileges. Executable not set-uid
To quickly get this fixed on your cPanel server execute the following command:
chmod +s /opt/suphp/sbin/suphp
This should fix the issue instantly.
If you’re finding issues starting VM’s on your Citrix XenServers due to ballooning issues as mentioned below:
$ sudo xe vm-start name-label=vm1
The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem.
message: Failure(“The ballooning daemon is not running”)
Then try this command then restart VM to find it working.
$ sudo xe-toolstack-restart
Stopping xapi: .. [ OK ]
Stopping the v6 licensing daemon: [ OK ]
Stopping the memory ballooning daemon: [FAILED]
Stopping perfmon: [FAILED]
Stopping the fork/exec daemon: [ OK ]
Stopping the multipath alerting daemon: [ OK ]
Starting the multipath alerting daemon: [ OK ]
Starting the fork/exec daemon: [ OK ]
Starting perfmon: [ OK ]
Starting the memory ballooning daemon: [ OK ]
Starting the v6 licensing daemon: [ OK ]
Starting xapi: ……start-of-day complete. [ OK ]
Thanks for the pointers by https://www.krzywanski.net/archives/919