Possible bug in Virtualmin post action scripts during DELETE_DOMAIN action on alias sub-servers

Hi Guys,

I've found a possible bug in the Virtualmin post action scripts:

During DELETE_DOMAIN action on alias sub-servers as part of the deletion of their parent, Custom fields presented via VIRTUALSERVER_FIELD_FIELD_NAME contain the values from the parent server.

Example: CUSTOM_ID is defined is a custom field. In the domain 'testersson.com' this is defined as '12345' and in its alias domain 'testersson.example.org' as '09876'

We attempt to delete the domain 'testersson.com', and test the value of $VIRTUALSERVER_FIELD_CUSTOM_ID

Expected result: testersson.example.org - 09876 testersson.com - 12345

Actual result: testersson.example.org - 12345 testersson.com - 12345

Further testing shows this also happens for MODIFY_DOMAIN.

Status: 
Closed (fixed)

Comments

Thanks for pointing this out .. I will fix this in the next release.

Hi Jamie,

Any idea when the next release will be, released?

Probably in a few days..

Cool - that'll be exciting! :-)

Hey Jamie

Just touching base to find out when the next VM release will be as we're looking forward to this fix :)

Best wishes!

Virtualmin 3.97 should be out now -- if you're having problems seeing or installing it, let us know though.

Not seeing the update yet, but definitely keeping an eye out. 2 to 3 days usual for it to be available in all Centos 6 repos?

Hi Jamie,

We've installed Virtualmin 3.97 and re-tested this feature.

The bug is still present, can you please confirm that this fix has been committed to this release?

Best wishes!

It looks like my first fix for this problem was incomplete :-(

A proper fix will be in the 3.98 release though.

Any chance you can provide a patch file in the meantime?

I've attached a diff file to this bug report, for the file /usr/libexec/webmin/virtual-server/virtual-server-lib-funcs.pl . You would need to run /etc/webmin/restart after applying it though.

Great thanks Jamie! We'll test it today.

Hey Jamie,

Thanks again for the patch.

We've tested with the patch and the bug still exists, the environment variable is still set to the parent server and not to the sub-server that is being deleted.

Over to you.

This might be a silly question, but did you run /etc/webmin/restart after applying the patch?

This might be a silly question, but did you run /etc/webmin/restart after applying the patch?

Yes, several times. No change.

Hey Jamie

Were you able to reproduce the bug with the latest patch applied? Or does it work for you? If it works, then maybe I need to provide more information on how to reproduce.

Cheers!

I wasn't able to re-produce this, sorry. Could you tell me more about the exact steps needed to re-produce it?

Hi Jamie,

Ok, so first up we're using a custom field to store some data that our post action script depends on. In our case, called LINODE_ID

So I create a server and an alias for this server with different values for LINODE_ID (for our script these are actually stored after server creation by the post-action script, via a call to CLI modify-custom, ie /usr/sbin/virtualmin modify-custom --domain $VIRTUALSERVER_DOM --set "LINODE_ID ${idstring_generated_by_remote_server}"). This is fine and in the Virtualmin interface I can see that the different values are stored.

Now I try to delete the parent server. Before the post action script is run for the parent server, it deletes the alias, running the post action script on that - debugging shows that during this call of this script, the value of ${VIRTUALSERVER_FIELD_LINODE_ID} is that of the parent server, not the alias.

Note: This only seems to affect custom fields.

Cheers.

I tested this again, with API commands like :

virtualmin create-domain --domain bugtarget.com --dir --unix --pass smeg
virtualmin create-domain --domain bugalias.com --alias bugtarget.com --dir
virtualmin modify-custom --domain bugtarget.com --set "address 55 Foo St"
virtualmin delete-domain --domain bugtarget.com

and a pre-change script that just runs env >/tmp/before.out.$VIRTUALSERVER_DOM

The results were as expected :

$ grep FIELD /tmp/before.out.bug*
/tmp/before.out.bugalias.com:PARENT_VIRTUALSERVER_FIELD_ADDRESS=55 Foo St
/tmp/before.out.bugtarget.com:VIRTUALSERVER_FIELD_ADDRESS=55 Foo St

So if you then try:

virtualmin create-domain --domain bugtarget.com --dir --unix --pass smeg
virtualmin create-domain --domain bugalias.com --alias bugtarget.com --dir
virtualmin modify-custom --domain bugtarget.com --set "address 55 Foo St"
virtualmin create-domain --domain bugalias.com --set "address 56 Bar Ave"
virtualmin delete-domain --domain bugtarget.com

I would expect:

grep FIELD /tmp/before.out.bug*
/tmp/before.out.bugalias.com:PARENT_VIRTUALSERVER_FIELD_ADDRESS=55 Foo St
/tmp/before.out.bugalias.com:VIRTUALSERVER_FIELD_ADDRESS=56 Bar Ave
/tmp/before.out.bugtarget.com:VIRTUALSERVER_FIELD_ADDRESS=55 Foo St

But according to my testing you would instead get:

grep FIELD /tmp/before.out.bug*
/tmp/before.out.bugalias.com:PARENT_VIRTUALSERVER_FIELD_ADDRESS=55 Foo St
/tmp/before.out.bugalias.com:VIRTUALSERVER_FIELD_ADDRESS=55 Foo St
/tmp/before.out.bugtarget.com:VIRTUALSERVER_FIELD_ADDRESS=55 Foo St

As in: the value for bugtarget.com in bugalias.com

What I get is :

$ grep FIELD /tmp/before.out.bug*
/tmp/before.out.bugalias.com:VIRTUALSERVER_FIELD_ADDRESS=56 Bar Ave
/tmp/before.out.bugalias.com:PARENT_VIRTUALSERVER_FIELD_ADDRESS=55 Foo St
/tmp/before.out.bugtarget.com:VIRTUALSERVER_FIELD_ADDRESS=55 Foo St

which looks correct.

Could you email me at jcameron@virtualmin.com the virtual-server-lib-funcs.pl file from your system so I can check that the patch was applied correctly?

Hi Jamie,

Email sent with patched copy of virtual-server-lib-funcs.pl

Cheers!

Thanks for that file - unfortunately, it is exactly the same as mine, which works fine!

When you see this problem, are you deleting a domain via the delete-domain API call, or via the web UI .. and if the latter, on which page?

Hi Jamie,

Was either from the command line or /virtual-server/delete-domain.cgi

However.... I noticed while simplifying our script for faster, less-destructive debugging, that the last time I did the same, I'd introduced an environment parsing error - So the error was now on our end. Script now works perfectly. Thanks for your help, and apologies for dragging things out past the end :/

Ok, glad you got it working!