I dont use it either. I just wrote my own installer wrapper script which sets up the stuff I use. I was using the old way where you copy files to the installer directory like ns1.txt and such.
I can just update my wrapper to use the variables.
DirectAdmin 1.63.2 has been released
- Thread starter fln
- Start date
I can just update my wrapper to use the variables.
I dont use the straight setup.sh. Where you get questions from the script. I use the preinstall method. My install is all scripted. Since what I need is the same every time.
In general I use this https://docs.directadmin.com/gettin...iew.html#options-for-script-installation-mode
excerpt from my code.
Code:
touch /root/.preinstall
echo 2.0 >/root/.custombuild
echo ${rootemail} >/root/.email.txt
echo "dns3.${svrdomainname}" >/root/.ns1.txt
echo "dns2.${svrdomainname}" >/root/.ns2.txt
printf "Here is what you have set for DA setup configs.\n"
printf "CustomBuild version set to:\n"
cat /root/.custombuild
printf "Email set to: "
cat /root/.email.txt
printf "Nameservers set to:\n"
cat /root/.ns1.txt
cat /root/.ns2.txtThere is not enough info here.
Please add a full list of variables. Also can you give descriptions of what they do / where they write to. Also are they required to be Upper Case?
Example
DA_EMAIL does it write to /usr/local/directadmin/data/users/admin/user.conf?
DA_NS# are the supposed to write to /usr/local/directadmin/data/users/admin/user.conf? OR The DA.conf?
I can export them prior to runing setup.sh but they don't seem to actually do anything.
Lets say I do
Code:
cd /root || return
DA_EMAIL="some email"
DA_NS1="dns.server.com"
bash <(curl -Ss https://www.directadmin.com/setup.sh) autoWhat should this do? is this syntax ok?
Is there away you all can confirm in setup.sh or install.sh that these Variables are set and printf it to the screen? currently the is no ouptput to the screen to notify the Admin they are set and working. I have to go throught the entire install then look randomly at the system to find they are not working.
wila
Verified User
- Joined
- Dec 15, 2017
- Messages
- 93
@fln sorry missed you replied.
debian 10, so with systemd and it was a 1.63.1 to 1.63.2 update.. I never stay behind for long.
No problem on the "out of ideas", got it back to work within a few minutes.
Was mostly posting it as a "this is how I solved it" part and perhaps someone who had ideas on what might have happened.
Thanks for the questions & ideas on where to look.
- Joined
- Aug 30, 2021
- Messages
- 1,124
@wila, I think you have old directadmin service description file. Please check
diff -u /etc/systemd/system/directadmin.service /usr/local/directadmin/scripts/directadmin.service, if files are not the same please do:
Code:
# cp /usr/local/directadmin/scripts/directadmin.service /etc/systemd/system/directadmin.service
# systemctl daemon-reload- Joined
- Aug 30, 2021
- Messages
- 1,124
Hi @bdacus01, I will try to be concise, if the discussion gets out of hand we could move it to separate thread.
All the variables are listed in the docs. If we add more we will update the docs accordingly.
Yes they need to be in upper case. This is a common convention for environment variables, helps to separate them from local shell variables.
You should not really care where this information is being stored. The idea is that if we ever decide to move config values around we could change it in DA and in the install scripts. If everyone starts to try manually setting variables in the correct files (without passing them to the install script via environment variables) it will be nearly impossible to change anything in the future. To environment variables is our interface to customize the installer. You can check script contents to track where this data is being stored but we give no guarantees it will not change in the future.
In the example above the variables were set as local shell variables and were not passed to the script. There are two ways to pass it to the script.
Exporting variables local shell environment (without export command they are local shell variables and are not being passed down to other scripts):
Setting environment variables on script invocation:
This is actually a good suggestion we were considering this internally. At the moment we are making a lot of changes to install scripts so kind of pushed all cleanup and nicer output for later. We will make it better in next release.
All the variables are listed in the docs. If we add more we will update the docs accordingly.
Yes they need to be in upper case. This is a common convention for environment variables, helps to separate them from local shell variables.
You should not really care where this information is being stored. The idea is that if we ever decide to move config values around we could change it in DA and in the install scripts. If everyone starts to try manually setting variables in the correct files (without passing them to the install script via environment variables) it will be nearly impossible to change anything in the future. To environment variables is our interface to customize the installer. You can check script contents to track where this data is being stored but we give no guarantees it will not change in the future.
In the example above the variables were set as local shell variables and were not passed to the script. There are two ways to pass it to the script.
Exporting variables local shell environment (without export command they are local shell variables and are not being passed down to other scripts):
Code:
cd /root || return
export DA_EMAIL="some email"
export DA_NS1="dns.server.com"
bash <(curl -Ss https://www.directadmin.com/setup.sh) autoSetting environment variables on script invocation:
Code:
cd /root || return
DA_EMAIL="some email" DA_NS1="dns.server.com" bash <(curl -Ss https://www.directadmin.com/setup.sh) autoThis is actually a good suggestion we were considering this internally. At the moment we are making a lot of changes to install scripts so kind of pushed all cleanup and nicer output for later. We will make it better in next release.
wila
Verified User
- Joined
- Dec 15, 2017
- Messages
- 93
@fln amazing!
That was a very good guess.
and that certainly explains why it was only that debian machine and not on a similar debian DirectAdmin host that I manage for a customer.
I fully expect that to have fixed it.
Thanks!
That was a very good guess.
Code:
# diff -u /etc/systemd/system/directadmin.service /usr/local/directadmin/scripts/directadmin.service
--- /etc/systemd/system/directadmin.service 2020-02-24 12:56:03.376793488 +0100
+++ /usr/local/directadmin/scripts/directadmin.service 2021-12-05 16:32:59.566292313 +0100
@@ -3,13 +3,13 @@
# systemctl --system daemon-reload
[Unit]
Description=DirectAdmin Web Control Panel
-After=syslog.target network.target
+After=syslog.target network-online.target
Documentation=http://www.directadmin.com
+Wants=network-online.target
[Service]
-Type=forking
-PIDFile=/run/directadmin.pid
-ExecStart=/usr/local/directadmin/directadmin d
+Type=notify
+ExecStart=/usr/local/directadmin/directadmin
ExecReload=/bin/kill -HUP $MAINPID
WorkingDirectory=/usr/local/directadmin
LimitNOFILE=65535I fully expect that to have fixed it.
Thanks!
Hey fln,
I have been away a bit. I have been lurking and I have seen the good work you have been doing. So glad development is moving ahead and the communication is better.
So then theses are local variables since they are in lowercase?
Basic options can be customized by exporting environment variables set to the desired values like so:
export php1_release=8.0
For PHP modules:
export php_imap=yes
Are there other variables like these?
or
could I do them like
What if I really want to do something like. I might not have that correct as I am not super at scripting.
fln so great to talk to you.
I have been away a bit. I have been lurking and I have seen the good work you have been doing. So glad development is moving ahead and the communication is better.
HAHAHA is my reputation preceding me?
Yes but they are all scatted. I am looking for one concise document that list all the variables and there purpose. Example would be like: https://docs.directadmin.com/direct...irectadmin-conf-values-and-how-to-change-them
For this I am thankful. I hope you all will continue to make it better. Its come a long way even before your time.
Well with my limited ability. I might need to understand how the system works. We are all Men and fallible so it helps to understand as best as possible. Also I tend to care about stuff sometimes to a fault. So I hear your advice as well.
Yes thanks.
So then theses are local variables since they are in lowercase?
export php1_release=8.0
For PHP modules:
export php_imap=yes
Are there other variables like these?
Ok this more of what I mean by more documentation. This type of multiple variable example is not in the documentation. So if you have multiple variables they need to be all in one line?
or
could I do them like
Code:
cd /root || return
export DA_EMAIL="some email" \
export DA_NS1="dns.server.com" \
bash <(curl -Ss https://www.directadmin.com/setup.sh) autoWhat if I really want to do something like. I might not have that correct as I am not super at scripting.
Code:
[email protected]
server=myserver.com
cd /root || return
export DA_EMAIL="${myemail}"
export DA_NS1=dns."${server}"
bash <(curl -Ss https://www.directadmin.com/setup.sh) autoThanks.
fln so great to talk to you.
- Joined
- Aug 30, 2021
- Messages
- 1,124
@bdacus01, thanks for encouragement 
. Feedback on the forums helps us better understand what we can improve.
Part of confusion here might be a mixture of
Full list of
Same ones are in the docs page.
However
Regarding passing the variables to the script:
is identical to:
Shell interpreter takes care of chomping new-lines escaped by
You need to export them only if you want them survive in the current shell session. In other words to survive between multiple command executions.
One more thing about magic files controlling the installation. Before we started refreshing installation scripts same settings were available by creating magic files in root home:
They still do work (for backwards compatibility) but we really want to get rid of them and start using environment variables only. That is why docs do not mention it at all. And please switch to environment variables if you used files before. We will sooner or later drop support for magic files.
Key reasons for such decision:
. Feedback on the forums helps us better understand what we can improve.Part of confusion here might be a mixture of
custom-build options vs setup.sh options.Full list of
setup.sh options are here, they are available:
Code:
# ./setup.sh --help
...
You may use the following environment variables to pre-define the settings:
DA_CHANNEL : Download channel: alpha, beta, current, stable, [commit-hash]
DA_EMAIL : Default email address
DA_HOSTNAME : Hostname to use for installation
DA_NS1 : pre-defined ns1
DA_NS2 : pre-defined ns2
Just set any of these environment variables to non-empty value (for example, DA_SKIP_CSF=true) to:
DA_SKIP_FASTEST : do not check for fastest server
DA_SKIP_CSF : skip installation of CFS firewall
DA_SKIP_MYSQL_INSTALL : skip installation of MySQL/MariaDB
DA_SKIP_SECURE_PHP : skip disabling insecure PHP functions automatically
DA_SKIP_CUSTOMBUILD : skip all the CustomBuild actions
DA_INTERACTIVE_CUSTOMBUILD : run interactive CustomBuild installation if DA_SKIP_CUSTOMBUILD is unset
...Same ones are in the docs page.
However
custom-build options are in lowercase and can be stored in a file (because there are a lot of them). You can find a full list of them in /usr/local/directadmin/custombuild/options.conf. And they tend to grow over time as custom-build starts to manage and install more software. That is part of the reason why they are not listed fully in the docs.Regarding passing the variables to the script:
Code:
VAR1=aaa \
VAR2=bbb \
./myscript.shis identical to:
Code:
VAR1=aaa VAR2=bbb ./myscript.shShell interpreter takes care of chomping new-lines escaped by
\ symbol and convert this command to single line. Thus there is no need for export keywords since we are actually setting variables for this particular script before execution like in single line mode.You need to export them only if you want them survive in the current shell session. In other words to survive between multiple command executions.
One more thing about magic files controlling the installation. Before we started refreshing installation scripts same settings were available by creating magic files in root home:
/root/.use_hostname- for setting custom hostname/root/.email.txt- for setting admin email/root/.ns1.txtand/root/.ns2.txt- for setting NS servers/root/.skip_get_license- to skip license download step/root/.skip_csf- to skip CSF installation/root/.using_fastest- to skip fastest mirror detection
/root/.preinstall and /root/.custombuild is not used anymore.They still do work (for backwards compatibility) but we really want to get rid of them and start using environment variables only. That is why docs do not mention it at all. And please switch to environment variables if you used files before. We will sooner or later drop support for magic files.
Key reasons for such decision:
- We do not pollute file system with stuff that is used only once
- We do not have to worry about formatting issues - for example hostname of the server being on second and not fist line of the file
- It is easier to document environment variables in the script usage page
- Environment variables are easier to integrate in other scripts and prevents
Always I try to be positive.
Correct and confusion is a bad thing. It should be corrected with Order... as Chaos is not good. This is were better documentation comes in it creates order.
Ah thanks
I see. I didnt understand it was intended as same as an option file entry.
Code:
export php1_release=8.0Seems not needed when you can just copy the option.conf correct with what you want before running setup.sh. thanks for the explanation.
yes I used these they a great for shell scripting.
I alway set the hostname on the server with the OS. As its required.
Are you also saying the variables need to be set in some kind of sequence?
Totally agree. We all just need to fully understand how it works.
If these are depricated is that documented somewhere? How would I find out stuff like this?
Thanks
Max Kelada
Verified User
Hello everyone!
Is there a way to update DA directly? I'm running DA 1.62 on Ubuntu 20.04. Yesterday it was 16.04 but DA said it was too old to get updates. Ok, i've upgraded it to 20.04, but DA still shows I'm running Debian 8.0. Of course I double checked.
I tried manual DA update - not working.
I've changed license OS info on DA site - but nothing changes.
I realize now that I need to somehow change OS info in DA on my server, but I don't know how.
Is there a way to update DA directly? I'm running DA 1.62 on Ubuntu 20.04. Yesterday it was 16.04 but DA said it was too old to get updates. Ok, i've upgraded it to 20.04, but DA still shows I'm running Debian 8.0. Of course I double checked.
I tried manual DA update - not working.
I've changed license OS info on DA site - but nothing changes.
I realize now that I need to somehow change OS info in DA on my server, but I don't know how.
If you've changed the OS on the licensing page, you may try manual update instructions on pre-release instructions (can be found in your clients area).