Dear all,
I don’t know how to solve this problem. How can I disable it without any encryption? It really make me into trouble.
I believe this is fixed in the latest version of virtualmin-config.
Try this:
# virtualmin config-system --include ProFTPD
If that doesn’t do it, you can edit /etc/proftpd/conf.d/virtualmin.conf and change the value for TLSRequired to off and restart proftpd.
Thanks a lot. value for TLSRequired to off and restart proftpd. It works. It costed me 5 hours.
Oh, dear!
While we all like to figure things out ourselves, and I appreciate your dedication to solving problems, you shouldn’t hesitate to ask us if you get stumped (you can ask here or in the issue tracker, since you’re a Pro customer). Sometimes it’s a known issue and we’ll have a fix right away.
I’ve also confirmed this is fixed in the virtualmin-config package in our repos, so new installs won’t have this problem, and running the command I gave above will always fix it for systems that currently have the problem.
Yes. I love professional version. Really, it is much cost effective than others. And also, I like the script installation though I disable for my client as these application cost me a lot of CPU.
Hi Joe, I am not trying to be difficult here, but seen few posts on forums regards this command - perhaps can someone update docs here on virtualmin.com site? It would really help around. thanks.
Edit: I added docs for it to the CLI docs section.
Yes, I’ll add some docs for it. It is self-documenting however…you can ask it for docs:
# virtualmin config-system --help
And, you can ask it to list its available plugins and bundles with the --list-plugins and --list-bundles flags. It’s still quite new, and is still mostly an internal tool; we use it for the installer. These post-installation uses aren’t really common, though it’s come up a lot lately as I fix bugs in the default installation and ask people to run it again with the new version so they get the new config.
So, I guess what I’m trying to say is that you almost certainly don’t need/want to use it unless I tell you to (or you have searched and found a problem where I told someone else to, and your problem is exactly the same) or you are developing your own custom version of the installer (in which case, you’ll need to follow the development over on the github: https://github.com/virtualmin/Virtualmin-Config ). It’s not a general purpose tool (though it might become one, eventually).
Ah I did not even know there is command for that, which is totally awesome! - what I was about is some docs online (not for me but for others who have less glue in background…) I already follow virtualmin git, thank you! 
Yeah, it was a long time coming. We really try to make everything available via a CLI and API, so that folks can automate everything, while also having good UI coverage. But, the installation is really complex, really specific to the distro/version it’s being installed on, etc. so it took a while to get it abstracted into a program that actually worked, was extensible and maintainable, etc. But, I’m happy with it, so far. It makes it so much nicer to add new features to the installation and makes it so much easier to fix bugs. It used to require rebuilding the very janky virtualmin-base packages, which intermingled dependencies and the installation. Those deps have now been divided into their own thing (yum groups or metapackages), and virtualmin-config just does configuration.
Being modular makes it easier for folks to create their own extensions to the installer, as well. It also uses standard Perl module installation, so you can actually build a standard Perl module that sub-classes Virtualmin::Config::Plugin, and it’ll be installable using normal Perl processes (so making RPM, deb, etc. is easy, but also cpanm should work). I haven’t documented that, but because it’s completely bog-standard stuff, it doesn’t really need unique docs, unlike most of our stuff which uses its own module system that Jamie developed decades ago.