Custom Fields for post sub-server installation

8 posts / 0 new
Last post
#1 Mon, 11/29/2010 - 12:23

Custom Fields for post sub-server installation

Hi, I'm having difficulties in getting any custom fields to work in a script that I'm running post installation of a sub-server in the GPL version of Virtualmin (Version 3.82) on Ubuntu (10.04). I have setup two custom fields called "title" and "dbname". The title field should update a parameter in a config file for a cms I'm installing, and the dbname is used for a sql script that I run to inject the cms's default database.

I'm using sed in interactive mode to replace the text in the files required, but it deletes the text that needs replacing and doesn't substitute it with the variables I supply it. I have tested sed from the command line to see if it is working properly and it seems that it is, so I have concluded that the variables being passed to the sed command are null or they haven't been declared properly on my behalf.

Questions are as follows:

  1. Are my server variables in the script below correctly formed?
  2. Is there a better way to do this, can I put placeholders in my files that reside in my /etc/skel/ directory.
  3. Also can you make a script to execute depending on the server/sub-server template that you choose when creating the domain?
sed -i 's:expressionengine-db-tochange:'$VIRTUALSERVER_FIELD_dbname':g' $VIRTUALSERVER_HOME/public_html/_resources/expressionengine.sql
mysql --user=$VIRTUALSERVER_USER --password=$VIRTUALSERVER_PASS --database=$VIRTUALSERVER_USER < $VIRTUALSERVER_HOME/public_html/_resources/expressionengine.sql
sed -i 's:expressionengine-db-tochange:'$VIRTUALSERVER_FIELD_dbname':g' $VIRTUALSERVER_HOME/public_html/vinculum/expressionengine/config/database.php
sed -i 's:Expression Engine Site:'$VIRTUALSERVER_FIELD_title':g' $VIRTUALSERVER_HOME/public_html/vinculum/expressionengine/config/config.php
chmod 666 $VIRTUALSERVER_HOME/public_html/vinculum/expressionengine/config/config.php
chmod 666 $VIRTUALSERVER_HOME/public_html/vinculum/expressionengine/config/database.php
chmod 777 $VIRTUALSERVER_HOME/public_html/vinculum/expressionengine/cache/
chmod 777 $VIRTUALSERVER_HOME/public_html/images/avatars/uploads/
chmod 777 $VIRTUALSERVER_HOME/public_html/images/captchas/
chmod 777 $VIRTUALSERVER_HOME/public_html/images/member_photos/
chmod 777 $VIRTUALSERVER_HOME/public_html/images/pm_attachments/
chmod 777 $VIRTUALSERVER_HOME/public_html/images/signature_attachments/
chmod 777 $VIRTUALSERVER_HOME/public_html/images/uploads/
Thu, 12/02/2010 - 17:12

Anyone? Any ideas on these questions?

Thu, 12/02/2010 - 17:59

According to the documentation found here:

the variable names should be $HOME and $FIELD_fieldname, without the VIRTUALSERVER in front of it.

Does that help?

Sun, 12/05/2010 - 23:10

I had a Similar problem and Jamie pointed out to me that the variables have to be in all capitals for them to be translated. eg FIELD_DBNAME.

hope this is of help


Mon, 12/06/2010 - 04:53

Hi I tried to use the $HOME variable but it didn't work, came back with an error saying that it couldn't find the sql file location, it was trying to use "root" as the $HOME variable eg. root/public_html/_resources/expressionengine.sql (if I used $VIRTUALSERVER_HOME it doesn't give me an error about the file location).

The reference to the variables that you posted seems to be from a legacy document, I gathered this from a note at the beginning of the page, so I followed the link to the new documentation and it says to use $VIRTUALSERVER_ in the example script on this documented page .

I tried to use the $FIELD_dbname variable and also the alternative $FIELD_DBNAME syntax but neither worked, both times the script returns an error displaying that the sql script requires a database defined after 'USE' (which is where I'm trying to replace the placeholder text in the sql script with SED, but all it seems to do is delete the placeholder text but not replace it with the variable that I am trying to specified in the script.

Mon, 12/06/2010 - 05:03 (Reply to #5)

to see what variables VM is making available to your script, at the top of your script just do

/usr/bin/env > /tmp/my_vm_env

Then have a look in /tmp/my_vm_env and you'll see all the env vars vm sets

Mon, 12/06/2010 - 09:41

Thanks for that information Chris, that did the trick, I managed to pull out the variables I needed from that temp file, although I seem to be having a SED issue with an error of "unterminated `s' command sed", I'm thinking that it's got to do with spaces in variable strings that are being unterminated.

Tue, 12/31/2013 - 15:55

is there any recommended way for exposing such custom fields to the LAMP runtime environment so that shtml/php scripts can use these fields ?

Specifically, I am thinking in terms of being able to:

  • have server-sideprofiles with custom fields
  • which can be configured as part of the virtualmin server template
  • during creation, select relevant profiles via checkboxes
  • specify if fields are optional or required
  • introduce additional field types for validation (e.g. IP, host, email)

So am looking for a simple way to expose certain info to the runtime environment during server creation or when updating/editing a server.

If this feature could be extended accordingly, it could be highly useful to easily provide certain setup info to scripts - i.e. also for the script installation routine - e.g. in terms of passing DB name, DB user and DB password via variables to the script - which would greatly simplify migrating servers.

Background: I recently migrated a LAMP app to another host and had to manually edit a ton of php and shtml / template files, i.e. to replace hardcoded credentials (db/user/pass) but also hardcoded paths.

If this sort of info could be exposed via runtime env vars, scripts could either check the environment or use the virtualmin CLI tools to look up a certain key/value pair.

Another use-case would be saving your google analytics code as a custom field and having it automatically inserted in php/shtml files just by getting $VIRTUALSERVER_GOOGLE_ANALYTICS.

If certain lookup keys could be provided and required by default, migrating websites across different servers could become pretty straightforward.

And in combination with webmin's powerful clustering support, we'd be halfway there to use webmin for script installation purposes analogous to simplescripts, scriptacolous or installatron.

So I am basically thinking in terms of encapsulating the concept of "custom fields" and wrapping them in "profiles" where additional field types can be specified for validation purposes, but also to specify if a field is required or optional. Such profiles could then be chained together in a "wizard"-like fashion, which could greatly simplify maintaining and migrating virtual servers.

Thoughts ?

Topic locked