DirectAdmin 1.63.2 has been released

bdacus01

Verified User
Joined
Jul 22, 2017
Messages
3,741
Location
Murfreesboro
Because I don't want to use the integration between BFM and CSF,
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.
 

bdacus01

Verified User
Joined
Jul 22, 2017
Messages
3,741
Location
Murfreesboro
Makes life a lot easier then typing command line stuff.
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.txt
 

bdacus01

Verified User
Joined
Jul 22, 2017
Messages
3,741
Location
Murfreesboro
Are there variables for preinstall and CB version 2

touch /root/.preinstall
echo 2.0 >/root/.custombuild

More better is there a complete documented list of all the Variables...
 

bdacus01

Verified User
Joined
Jul 22, 2017
Messages
3,741
Location
Murfreesboro
The key change is that it is now controlled with the environment variables. You can find it in the docs here - https://docs.directadmin.com/gettin...ning-the-installation-with-predefined-options
There 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) auto

What 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
69
@wila, nothing suspicious in the logs. Older DA versions I think used to have less tight systemd integration support (it was tracking pid from file rather than supervising directly started process). Line directadmin.service: Killing process 2970 (n/a) with signal SIGKILL is hinting that. A long shot at guessing the root cause is that you had quite old DA installation, but if it was 1.63.1 -> 1.63.2 update than I am out of ideas.
@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.
 

wila

Verified User
Joined
Dec 15, 2017
Messages
69
FWIW, just upgraded from 1.63.2 first release to 1.63.2 second release and it happened again.
After running
Code:
systemctl start directadmin
back in business, once more.
 

fln

Administrator
Staff member
Joined
Aug 30, 2021
Messages
445
@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
 

fln

Administrator
Staff member
Joined
Aug 30, 2021
Messages
445
Hi @bdacus01, I will try to be concise, if the discussion gets out of hand we could move it to separate thread.

There is not enough info here.
Please add a full list of variables.

All the variables are listed in the docs. If we add more we will update the docs accordingly.

Also can you give descriptions of what they do / where they write to. Also are they required to be Upper Case?

Yes they need to be in upper case. This is a common convention for environment variables, helps to separate them from local shell variables.

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?

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.

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) auto

What should this do? is this syntax ok?

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) auto

Setting 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) auto

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.

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.
 

apogee

Verified User
Joined
Jul 6, 2019
Messages
193
Location
Europe
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.
1+ great suggestion!

When is the next release planned? I have to set up a few servers soon (end of week) and want to update our scripts...
 

wila

Verified User
Joined
Dec 15, 2017
Messages
69
@fln amazing!
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=65535
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!
 

bdacus01

Verified User
Joined
Jul 22, 2017
Messages
3,741
Location
Murfreesboro
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.
if the discussion gets out of hand
HAHAHA is my reputation preceding me?
All the variables are listed in the docs.
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

If we add more we will update the docs accordingly.
For this I am thankful. I hope you all will continue to make it better. Its come a long way even before your time.

You should not really care where this information is being stored.
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 they need to be in upper case. This is a common convention for environment variables, helps to separate them from local shell variables.
Yes thanks.

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?

cd /root || return DA_EMAIL="some email" DA_NS1="dns.server.com" bash <(curl -Ss https://www.directadmin.com/setup.sh) auto
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) auto

What 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) auto

This is actually a good suggestion we were considering this internally.
Thanks.

fln so great to talk to you.
 

bdacus01

Verified User
Joined
Jul 22, 2017
Messages
3,741
Location
Murfreesboro
also in the old help documentation there used to be:

touch /root/.preinstall
echo 2.0 >/root/.custombuild

Are these needed?
 

fln

Administrator
Staff member
Joined
Aug 30, 2021
Messages
445
@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 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.sh

is identical to:

Code:
VAR1=aaa VAR2=bbb ./myscript.sh

Shell 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.txt and /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
Files /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
 

Zhenyapan

Verified User
Joined
Feb 23, 2018
Messages
1,579
Location
UA
DA_INTERACTIVE_CUSTOMBUILD : run interactive CustomBuild installation if DA_SKIP_CUSTOMBUILD is unset
---
it's old installer which asks each php/mysql/webserver etc?
 

bdacus01

Verified User
Joined
Jul 22, 2017
Messages
3,741
Location
Murfreesboro
thanks for encouragement
Always I try to be positive.
Part of confusion
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.
./setup.sh --help
Ah thanks
However custom-build options are in lowercase and can be stored in a file (because there are a lot of them).
I see. I didnt understand it was intended as same as an option file entry.
Code:
export php1_release=8.0

Seems not needed when you can just copy the option.conf correct with what you want before running setup.sh. thanks for the explanation.
magic files in root home:
yes I used these they a great for shell scripting.
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
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?
Key reasons for such decision:
  • We do not pollute file system with stuff that is used only once
  • It is easier to document environment variables in the script usage page
  • Environment variables are easier to integrate in other scripts and prevents
Totally agree. We all just need to fully understand how it works.

Files /root/.preinstall and [ICODE/root/.custombuild[/ICODE] is not used anymore.
If these are depricated is that documented somewhere? How would I find out stuff like this?

Thanks
 

Max Kelada

Verified User
Joined
Oct 14, 2006
Messages
20
Location
Russian Empire
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.
 

smtalk

Administrator
Staff member
Joined
Aug 22, 2006
Messages
10,574
Location
LT, EU
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.
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).
 
Top