These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for I've forgotten post install script for virtual ser on the new forum.
Web Hosting and Cloud Computing Control Panels
Hey Tony,
I think you're looking for System Settings -> Module Config -> Actions Upon Server and User creation.
In there is the option for running things when a Virtual Server is created.
Have a good one,
-Eric
Unfortunately there is no longer an "Actions Upon Server and User creation item in the list. Jamie had me undo the update users stuff in webmin. Could that be causing this to no longer appear?
Hrm, I'm not entirely certain what Jamie had you change, or what that means exactly, so it's hard to say :-)
What all did you modify, and what version of Virtualmin are you using? Is that Pro or GPL?
-Eric
3.64 Pro
Unfortunately I don't remember... It had to do with updating quotas when things changed. The group quotas weren't being updated. Unfortunately I've deleted the emails that give me the links to the bug tracking thing you guys use. I could search it and give a pointer to what he had me change (and why).
Would disabling updates to unix user/groups prevent this setting from showing?
I'll ask Jamie to take a look at this thread. As I'm not sure what you're talking about either. ;-)
I will note that the post/pre scripts for users is configured in the Users and Groups module configuration. This is separate from the Virtualmin settings Eric pointed you to. Perhaps that's what you have in mind?
--
Check out the forum guidelines!
I found where it is set.
The trouble is that when a post-install is run, there are at least 3 problems that I see:
1) The whole /var/skel (or what's defined for the primary domain is copied to /home/<user>/domains/<sub-domain> but is never used or accessed because the sub-domain is aliased in the parent domain. Hence any access via <sub>.<domain> never gets there (which it shouldn't). So the skeleton shouldn't be copied. It's a complete waste of space. Note that in the sub-server template, the /var/skel stuff is NOT defined. It should honor this.
2) The post install script should really be template based versus system based (or two separate actions). If it were, then #1 wouldn't be an issue (nor #3 in this case). It is re-run a second time when the sub-server is created. Hence it runs twice (and in my case) operates on the same content but in the /home/user/domains structure.
3) When run as a sub-server, the post-install is not setting VIRTUALSERVER_DB environment variable. Hence when the sub-server is created it (again in my case) uses a default value and the admin of the primary domain does not have permission on this database.
So my suggestion would be (to ensure compatibility), have 2 post-install actions. One that is global and runs every time any server is creaed (primary or sub). Two, have a separate post-install that is template based to be run when that template is utilized only. Three, fix the VIRTUALSERVER_DB problem. With these, it would be a workable scenario.
1) This is a bug really - the /etc/skel/public_html directory should be copied to the /home/parent/public_html/subdomain directory for it to be usable. I'll fix this in the next release ..
2) Since you can make use of variables like $VIRTUALSERVER_TEMPLATE in the post-install script, you have a lot of flexibility to copy content into new domains' directories however you like. Also, you can check the $VIRTUALSERVER_SUBDOM variable to see if a new domain is a sub-domain or not.
3) At the moment, sub-domains can't have databases.
One option may be to use sub-*servers* instead, which can also be sub-domains but don't have any of the limitations of sub-domains. They can have DBs, and their content is not under the public_html directory of the parent.
--
Check out the forum guidelines!
Regarding your points:
1) The whole intent behind creating temporary access (per the documentation) for a <domain> as <domain>.<parent> is to allow access to the actual site by the client before DNS swings. I do not want to have to explain that any changes they make will be lost when they start using their real domain. "I believe" that it should be and act like an alias.
2) I was not aware of that variable (I can't find a complete list anywhere). However, I still believe the post-install should be "template based" rather than "system based" (or at least an option for both).
3) Well, that makes sub-domains pretty useless and will not address the issues stated in the documentation. As it's implemented today (all but the copying of the /var/skel and the second running of the post-install) is behaviorally correct. I.e. when a client accesses <domain>.<parent> they get "aliased" to their real document root. Hence they have db access and full functionality until they utilize <domain>. Consider a client who is moving an online store of mystuff.com. It make take them a month of development to have their new store ready. At that time, they swing the DNS (re-point the nameservers) and their new store is up and running.
I strongly disagree with most of the intended changes or the way you feel it should work. Please review the recommendations in the documentation for automatically creating subs and why it's important.
So if you are trying to provide a way to grant access to a domain before the DNS changes, there are a couple of better ways this can be done in Virtualmin :
1) Say the real domain is example.com , and your hosting company's website is hosting.net. After creating example.com in Virtualmin as a top-level virtual server, you would create an alias domain for it called example.hosting.net. This would then be accessible even before example.com is register in DNS or re-pointed from it's old server.
2) Login to Virtualmin as the owner of example.com, select it from the menu, open the Services category and click View website via Webmin.
I agree about the post-install script being templatable .. that's a good suggestion. I will look into implementing this in the next release.
--
Check out the forum guidelines!
As I read the documentation and recommendations, that effectively was what I thought I was doing by:
[code:1]
System Settings/Server Templates
(select the template to edit)
Select 'Virtual Server Creation'
Selecting the 'Automatically create alias domain'/Create Under <domain> and entering the parent domain.
[/code:1]
I had hoped this would be a real alias. I.e. mailboxes accessed via <domain>.<parent> would go to the <domain> mailboxes and that the web site would be a Alias in Apache (which it is). Hence, when no longer needed, all I'd have to do is delete the alias but it would NOT affect any of the underlying data by doing so. As currently implemented, this is effectively what someone gets (other than mail and non Apache stuff). But I don't think the 'skel' directives should happen for an aliased domain.
Damn I hate this forum SW. Just entered a bunch of stuff and clicked submit and it all disappeared. So I will try again.
That's what I thought I was doing by:
System Settings/Server Templates
Selecting the template I wanted to edit.
Virtual Server Creation/Automatically create alias domain
Select 'Create under' and enter the domain name of the parent.
As I read the documentation, that's what it says to create an 'Alias'. Copying data, creating separate mailboxes, etc. is not 'aliasing'. The only thing aliased (it appears) is Apache. Hence, post-install should not be run, 'skel' stuff should not be duplicated, etc.
What am I missing? I'd like to be able to delete the 'alias' when it's no longer needed and have it NOT affect any of the underlying data that it pointed to (including mailboxes, public_html, logs, etc.)
Okay, this is the third attempt to post a comment on this topic in this forum. Can't we get forum software that actually works!!! Argh!
As I read the documentation, that's what I thought I was doing by:
[code:1]
System Settings/Server Templates
(select the template I want to edit)
Virtual server creation/'Automatically create alias domain'
Select 'Create under' and enter the parent domain name
[/code:1]
This should create an 'Alias' for the domain's information. As currently implemented, it creates copies of everything for the domain (mailboxes, 'skel' stuff, logs, etc.). The only thing truly 'Aliased' is Apache.
The intent is that this is temporary access. Once the customer starts to use their real domain, I should be able to delete this 'Alias' without really deleting any data (mailboxes, logs, etc.). But it appears that it creates a sub-domain versus an 'alias'. Again, the only thing aliased is Apache (but everthing in 'skel' (including public_html) is copied to /home/<user>/domains/<domain>.<parent>. However, it's not even accessible via Apache (and shouldn't be).
Why not just NOT do the copy of 'skel' stuff, DON'T run post-install and create a symbolic link where /home/<user>/<domain>.<parent> simply points to /home/<user>? Then you'd have an 'Alias'.<br><br>Post edited by: tbirnseth, at: 2008/12/27 16:39
Ok, so it sounds like you have automatic alias domain creation working already. In this case, the skeleton files are pretty much useless, and harmless. In the next Virtualmin release, I will prevent them from being copied at all for alias domains.
So, are these automatic alias domains not working? They should be independent of any link from the parent domain's web directory.
ps - I saw your post three times, so it looks like it did get submitted OK. Did you get some error message indicating that the posting failed?
--
Check out the forum guidelines!
Yes, they are working with the exception of $VIRTUALSERVER_DB not being defined. Also, post-install is run on the alias server creation that generates errors because of $VIRTUALSERVER_DB.
I do not know if I access a mailbox at <domain>.<parent> if it resolves to the actual mailbox in <domain> (it should in my opinion).
There may be other variables not defined but of course this can be resolved by simply not running the post-install and not copying the files when it's an alias server creation and/or having it be template based.
When I went back to the forum, the messages didn't appear. It could have been caused by my having the forum open in another tab. The other issue is the duplicate subject line issue that always seems to bite me.
Again they don't show when the forum message redraws but I will assume that you're seeing them!
Uh, okay. Shame on me... Multiple pages to this message thread! Duh!
You won't be able to access $VIRTUALSERVER_DB in the post-install script for the alias domain - but it will be accessible in the 'real' domain. Virtualmin will actually all the script *twice* - once for the alias domain, and then again for the real domain.
As for mailboxes, any address@realdomain.com should also be accessible as address@aliasdomain.com.
--
Check out the forum guidelines!