Jeremy Davis's picture

Got the Webmin to work. I was a bit confused because i was earlyer able to login with admin on webmin. And did not think of using root to login webmin. So All is working now!

Thanks for the info, although TBH, I'm not sure why you were able to log into Webmin as "admin"?! It should always be 'root' - with servers on AWS Marketplace being the exception - as that's a strict requirement of AWS.

Usually if i install a debian machine, i disallow root to be able to login remotely to the machine. Then i have to login with normal user account, then i sudo root myself. We did this default on all linux machines.

As you seem aware, under the hood TKL is Debian. So you can create a new sudo user if you want and disable root. Although I'm not sure how Webmin will cope? You may need some further config there there, but feel free to report any issues (or even success!) and I'll do what I can to assist. Or if you work it out, please share. It's probably a good thing to document for others that would prefer that.

Actually (t osupport AWS requirements), we do have a tool that creates a sudo user called 'admin' which does work with Webmin - although one of the things it does (which you may not like - but may be required for Webmin?) is it disables the sudo password - i.e. no password is required to run sudo. Running our built in tool it with no args will show the help:

turnkey-sudoadmin

Re context of root/sudo user: That is an ideological decision - one which quite a few technical server projects adopt.

Regardless, a sudo user on a Linux desktop is must! Only Linux Desktop users with a desire for pain and trouble run as root!

On a single user server IMO its more of a personal choice. Almost every command you will want to run will require root and it's security by obscurity at best and IMO just an extra layer of PITA (essentially "Simon says"). Unless there is at least some "real security" then security by obscurity can give a false sense of security. If you have the "real sec" covered, then there are things such as a sudo user that can raise the bar a bit.

There are security screws you can tighten to harden your server, some "real" and others additional security by obscurity. But with fail2ban and a good root password, I personally don't think it's necessary.

One other question, does turnkey have packages of software from the other appliances to install inside this one? Like for example installing media wiki next to redmine, so it runs on the same server.

You're no the first to ask that question! :) But strictly speaking no. Having said that, many of our users run TurnKey under LXC - e.g. as a Proxmox container. So whilst it's still a separate server, it uses very little additional resources. We have done Docker builds in the past - albeit via a hack that loads the full rootfs into a Docker container. So it is essentially the same scenario as LXC, but in Docker. IIRC the reason we stopped was issues with Docker, but AFAIK, that's been resolved upstream. I'd like to get back to doing Docker builds - even if via the hack I noted. But I've got a huge backlog and it's not a huge priority - we've only had a few requests to do them again since we stopped.

So if you don't want/have LXC, then OTTOMH the only way would be to manually install the secondary software yourself. Not very TurnKey... It should be possible to run the scripts we use to build all our appliances but it's not something we technically support and might have issues.

[...] Databases stay healthy.

Yay! :) Thanks for confirming.

Glad it's working out for you!