Change Domain Name fails when having pre scripts

Submitted by steen on Sat, 09/04/2010 - 10:57

Hello Folks!

There is a bug in virtualmin regarding changing domain name and post scripts.

When using commands to run before making or change to server or aliases, it is not possible to rename domains.

I tried both to have scripts putting all output of progress into a logfile and not. Problem is same. The scripts themself do nothing, they just check some variables.

There is absoultely no errors in scripts or output from them, all is redirected to /var/log/virtualmin.log. All work fine as long you do not try to rename a domain.

When you try to rename domain, it barks out with HTTP 500. In the miniserv.error logfile it comes: /virtual-server/rename.cgi : Bad Header

When those are "active" it fails. Command to run before making changes to a server Command to run before making changes to an alias

It works with: Command to run after making changes to a server Command to run after making changes to an alias

Please assist.

Status: 
Closed (fixed)

Comments

Submitted by JamieCameron on Sat, 09/04/2010 - 11:35

Does your before-change script exit with a non-zero status? You might want to make sure that it ends with :

exit 0

to indicate success.

Submitted by JamieCameron on Fri, 09/10/2010 - 17:18

Are you very sure that your command doesn't output anything?

You could suppress all output by adding the following to the end of the "command to run before making changes" :

>/dev/null 2>&1

Submitted by steen on Sun, 09/19/2010 - 10:29

it is done, yet it barks out...

Submitted by JamieCameron on Sun, 09/19/2010 - 15:12

What do you have the pre and post-save script set to exactly? Just a simple shell script, or a complex shell command?

Submitted by steen on Mon, 09/20/2010 - 12:44

Hello Jamie!

Postscript is a more complicated script, it fiddles with smbldap and some other domain key stuff plus email aliases for one domain.

Postscript works, you can rename domains etc. no problem.

Prescript makes domain rename fails, it is a very simple script, stripped down to just echoing down in a file, it takes no arguments and it does not have any output at all.

!/bin/bash

echo "prescript test" >> /tmp/prescript.txt

Submitted by JamieCameron on Mon, 09/20/2010 - 15:10

Does this script actually get run before the rename, and write to /tmp/prescript.txt ?

Submitted by graham_howden1 on Mon, 11/29/2010 - 10:04

I have exactly the same problem, even when the pre script is set to:

!/bin/sh

exit 0

It errors out with 'Error - Bad Header' in the control panel when changing domain name and post script seems to fail to run.

Interestingly with both the pre and post enabled, the pre will run but the post will not and it will generate the bad header and nothing will have been done (the domain does not get renamed)

Submitted by JamieCameron on Mon, 11/29/2010 - 16:09

I just tested this with a pre script that contained only :

#!/bin/sh
exit 0

and the rename worked fine. Are you sure the pre script is set to be executable, with chmod +x /path/to/script.sh ?

Submitted by graham_howden1 on Mon, 11/29/2010 - 16:25

Yes it was +x, I double checked and it still has 'Error - Bad Header' when changing domain name

Submitted by JamieCameron on Mon, 11/29/2010 - 17:15

If you run that script manually at Webmin -> Others -> Command Shell, what does it output exactly?

Submitted by graham_howden1 on Mon, 11/29/2010 - 17:26

It just prints

path/to/script

and then nothing else

Submitted by JamieCameron on Mon, 11/29/2010 - 18:13

Ok, I thought of another issue - at System Settings -> Virtualmin Configuration -> Actions upon server and user creation , so you have "Always show output from pre and post commands?" set to "Yes" ? If so, does changing it to "No" help?

Submitted by JamieCameron on Mon, 11/29/2010 - 18:19

I looked further, and found a bug in the rename code that will be triggered when "Always show output from pre and post commands?" is set to "Yes", even if the pre-command doesn't output anything. This will be fixed in Virtualmin 3.83..

The work-around is to select "Only on error" for that option.

Submitted by graham_howden1 on Mon, 11/29/2010 - 18:27

Thanks, works for me now

Submitted by Issues on Mon, 12/13/2010 - 19:51

Automatically closed -- issue fixed for 2 weeks with no activity.