> This all coincides with a migration from Drupal 6 to Drupal 7, which has been a nightmare and has taken longer than every previous website migration we've done, including two migrations from completely unrelated content management systems and shopping carts.
Aww, I'm so glad I'm not on your team for that ;-) Even without following Drupal closely I can imagine your pain: new programming/design patterns, new php language features, major refactoring and a change to more modern rendering pipeline, templates and perhaps a new caching layer on top of perhaps a restructured data-layout? Am I close?
> I'd like to hear about your poor impression of Webmin. What, specifically, makes Webmin not something you would consider for your servers? I know about some of the persistent myths that follow Webmin around: Insecure, breaks things, incompatible with my favorite distro, ugly code (this is kinda true).
Mainly bad code and insecure (way back). But:
> But, many of those come from grumpy hard-line command line administrators that think no one should be allowed to be a system administrator if they can't do it all in a shell...we'll never win those folks over.
That's me ;-) As I said, not your target customer. Mainly I don't really want the level of access webmin needs to be effective, exposed as a web service. While that might be mostly religion at this point; I also realize that it mostly makes sense if no other core data is exposed as a web service. This is obviously the case for many people and businesses. [ed: just not for me as I prefer ssh/the command-line]
Would two-factor authentication and certificate-based authentication help alleviate some of those security concerns? Because Webmin has both of those.
We actually take security seriously, as any software that provides root-level access to a million servers must, though I don't pretend we will ever be bug-free or that we can ever guarantee security (even SSH has had major security bugs). We're considering setting up some sort of bug bounty to help sniff out security bugs, but haven't figured out how best to implement that.
I actually thought a bit about that after posting. I would be more inclined to use a web based admin interface today, than just a few years ago; the TLS stack is not as bad as it was; we've come further wrt ciphers - and the web servers themselves have seen (more) hardening.
The thing is; I already use ssh. Adding another network service doubles the attack surface.
Then there's the ux problem for browsers and certs. Using certs with ssh is complicated enough (it's still on my todo-list, I use/require keys - but key management is not trivial for more than a handful of servers).
Ssh also finally have easy/proper 2fa support now: setting up totp+keys is quite trivial. Add password+totp for sudo locally and you have half-decent ux and security.
And while ssh has had some security issues, it's been a while since the last big one. In contrast with all the things that go wrong with web apps (xss, session-hijack etc).
All that aside, certs+2fa (and the ability to disable pw auth) goes a long way.
Btw for any other grumpkins reading; I just discovered scoop and found out powershell seems to finally be usable in windows 8.1 pro even for part-time ms users.
Run>powershell
set-executionpolicy unrestricted -s cu
iex (new-object net.webclient).downloadstring('https://get.scoop.sh')
#yeah, I know - no signarure, code from curl...
#but this is windows, beggars can't be choosers
scoop bucket add extras #optional
scoop install ssh
If you want oneget, it's in the extras-bucket iirc:
scoop install oneget
But while scoop could use some love (eg vlc is a point release behind oneget/chocolaty) -- it's much nicer than the FindPackage mess IMNHO.
Aww, I'm so glad I'm not on your team for that ;-) Even without following Drupal closely I can imagine your pain: new programming/design patterns, new php language features, major refactoring and a change to more modern rendering pipeline, templates and perhaps a new caching layer on top of perhaps a restructured data-layout? Am I close?
> I'd like to hear about your poor impression of Webmin. What, specifically, makes Webmin not something you would consider for your servers? I know about some of the persistent myths that follow Webmin around: Insecure, breaks things, incompatible with my favorite distro, ugly code (this is kinda true).
Mainly bad code and insecure (way back). But:
> But, many of those come from grumpy hard-line command line administrators that think no one should be allowed to be a system administrator if they can't do it all in a shell...we'll never win those folks over.
That's me ;-) As I said, not your target customer. Mainly I don't really want the level of access webmin needs to be effective, exposed as a web service. While that might be mostly religion at this point; I also realize that it mostly makes sense if no other core data is exposed as a web service. This is obviously the case for many people and businesses. [ed: just not for me as I prefer ssh/the command-line]
So again, best of luck :-)