Here is the suexec log when I change ownership and group to root
[2021-07-09 07:36:06]: uid: (1001/netstore) gid: (1001/netstore) cmd: test2.pl
[2021-07-09 07:36:06]: target uid/gid (1001/1001) mismatch with directory (0/0) or program (0/0)
The log is clear that it wants to run as 1001/1001 (looks like netstore user and group). Why would you set it to root or wheel or anything else? suexec runs as the user you tell it to with SuexecUser/SuexecGroup and no other. Thatâs its job. Itâs just doing its job.
It is true. This is the configuration that we have been using on many versions of OS, first BSDI, then Freebsd, Then Centos, with Cpanel, that we have been using for over 10 years. But now with Cpanel changes, and pricing, I must get the solution working on alternative control palnels and OS.
So, first I would need to know what is the configuration settings/make file for the apache you install with Virtualmin, and how I can recompile and tweak with the settings that I discussed in the other threads.
I really have tried using this for 6 months, now I MUST find a working solution. So, if you can âshareâ your apache build techniques and if you include the source and build make files, then with these files maybe I can figure out a way to get it to work same as my current CENTOS 6, apache 2.4 configuation
https://netstores.com/CP/current_state_at_2019.json
https://netstores.com/CP/httpd.conf
Do you have any assistance on this recompile/configuration ?
And
How does virualmin scripts run in apache then with suexec?
We donât build Apache. Your OS vendor does.
Sorry, Iâm being short with you at this point, because I donât understand why you wonât just take my advice and make the thing work rather than demanding we turn Virtualmin into cPanel?
This has become a very frustrating conversation. Iâve told you exactly how to make this work today. Your software could be working right now.
1 Like
Joe, I am not intending for you to become frustrated @ all. My goal it to be able to use virtualmin as a replacement for cpanel.
Unfortunately the NetStores Shopping Cart Application has a 25 year history running as a system wide scripting bin. I can not change that. This was so any user or virtualhost could call up the system wide scritpts, tools, etc and use the shopping cart and catalog system. Many years of PERL development.
So, way back in the early days of apache, everthing ran under /var/www⊠and just like that cgi-bin That is how the application was built, but as virtual hosting became popular this was changed to public_html. There are a whole lot of changes but, but it is clear that the Apache build 2.4 on the Centos 6 that cpanelâs EasyApache4 has the ability to do system wide scripts (as you see in the conf file) that has the script alias for cpanel scripts.
I believe the easyApache4 is a configuration tool that compiles a new binary for apache, with all kinds of configuration settings. Then clearly, the allows the user admin interface to call up these scripts, probably similar to virtualmin, but I have not dissected enough yet, to know, and in the modules compiled into virtualmin apache are:
http://wwwc7.netstores.com/moduleshttpdvitualmin
In cpanel are:
https://netstores.com/CP/moduleshttpdcpanel
so I wonder how we can make this work for me?
Youâre conflating a bunch of unrelated problems here, most of which have nothing to do with Apache.
To add modules to Apache in Virtualmin, you install the module package from your OS vendorâs software repositories, and sometimes you may need to enable that module (e.g. in Debian/Ubuntu you use the a2enmod command, in CentOS, installing the module usually enables it). Sometimes you may need to add a third-party repo to get some of the less common or more unusual modules. We donât rebuild Apache in Virtualmin-land. Itâs just not something you should be doing. 99.99% of people do not need to, and nobody should want to, rebuild Apache.
But, it doesnât sound like you know what modules you need and use. Iâm not going to go over those lists and try to guess.
I can say, however, that even if you copy Apache exactly, it will not make your new system act like your cPanel system. Apache has little to do with what youâre asking for. (And, Virtualmin and cPanel also have little do with what youâre asking for, if I understand it correctly.)
To be clear, which I guess I wasnât: Applications being accessible and run by local users has nothing to do with Apache. Unless youâre talking about a web API where the users of the app(s) make web requests to localhost and the server does something. But if that were the case we wouldnât be talking about âsystemwideâ apps, because a web API donât care about being accessible to local users.
I donât understand your architecture, but somebody in this conversation needs to if weâre going to get anywhere, so itâs going to have to be you. Right now youâre talking around the problems and chasing what you believe is a solution (a cPanel-like Apache build), which I am about 95% certain is not in any way a solution. Who can run local applications is not an Apache concern, in any way.
2 Likes
Thank you Joe. So, I have done a small test that seems to work, ie:
Created the netstores application directory in one user directory, and added these 2 directives to httpd.conf
ScriptAlias /dwos-bin/ /home/netstore/netstores/dwos-bin/
And
<Directory /home/netstore/netstores/dwos-bin>
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
Require all granted
and was able to test just 1 perl test file, to get Hello world.
http://wwwc7.netstores.com/dwos-bin/test2.pl
So now I will start adding all the PERL modules nececssary for the NetStores Application, and see if I make progress.
Do you use perlinstaller like cpane for adding PERL modules?
Good lord, no. Thatâs another cPanel bug that we would never replicate. Install Perl modules, whenever possible, from your OS vendorâs software repos. Once again, for unusual or less popular modules, you may need to enable a third party repository. As a very last resort, you can use CPAN to install modules; we provide a GUI for that in the Webmin tab (do not do this lightly; from-source installs on a production system are a smell that should be avoided).
2 Likes
Joe, if you know anyone that may be able to understand the easyApache4 installer, configuration and Apache compiling on Virtualmin, maybe they can solve this for the long term. I will concentrate on getting the app to run in 1 user directory alone for now, installing all the Perl requirements, and see if I can get it to run on the base system provide with CENTOS 7.
will let you know how it goes.
easyApache is a cPanel feature. It does not exist outside of cPanel systems. If you need easyApache, you need cPanel. (But, you donât need easyApache. It is not the right solution to the problem.)
Any ideas the commands for doing so for CENTOS Operating system
CentOS Linux 7.9.2009 and the PERL your installer created?
Our installer did not create Perl. It came from your OS vendorâs software repositories, as did everything in a Virtualmin system other than our own packages.
On CentOS 7, yum is the system package management tool (CentOS 8 has dnf, but it can be called with yum and most command line arguments are the same).
There is a package manager GUI in Virtualmin that will use yum on CentOS (or apt-get on Debian Ubuntu) to install packages for you. Itâs under Webmin->System->Software Packages. Search for perl- for Perl modules, and mod_ for Apache modules (though I think some donât follow that convention).
We use system-standard tools for everything. This is our fundamental disagreement with cPanel. They donât (I wrongly assumed that everyone would agree with this and flock to our doors because the way cPanel does things is such a bad ideaâŠ). If you want to learn about your Virtualmin system, learn about your CentOS system, because they are almost completely the same thing; we use the standard system package manager to install the standard system Apache, Postfix, Mariadb, Bind, Perl, etc. packages, and we manage them as closely as possible to the usual way. This even means that Virtualmin config files for Apache look different on Debian and Ubuntu than on CentOS. We do it the Debian/Ubuntu way on those systems, and the CentOS way on CentOS systems. You chose an OS, we work with that OS. If you know CentOS, youâll know exactly where everything is on a Virtualmin system (with a couple of tweaks to suit a multi-tenant shared hosting environment with low-trust users).
So, learn about CentOS. That knowledge will all carry over to Virtualmin.
2 Likes
OK, Joe, thank you for your communication.
So, here is how I have been starting the process of each development server. I go to Vultr, create a Centos 7 server, then login, change password. Then run your software installation process for Centos 7, Download
wget http://software.virtualmin.com/gpl/scripts/install.sh
sudo /bin/sh install.sh
At this point your installer installs the PERL for this distro.
I did not, so here is where I am.
But the interesting thing about your install.sh, it did the PERL installation automatically., and I canât even find the perllocal that I have on other PERL systems on Cpanel Centos7. But that said, I followed your direction, but before I start installing the amount of PERL modules I need to, I am trying to get a list of the Current Installed Perl modules and Verison which I could always do on the other servers I have: ie this great tool.
for M in perldoc -t perllocal|grep Module |sed -e 's/^.*" //'; do V=perldoc -t perllocal|awk "/$M/{y=1;next}y" |grep VERSION |head -n 1; printf â%30s %s\nâ â$Mâ â$Vâ; done |sort
But this does not work with the PERL installation installed by install.sh I even tried to manually install PERLLOCAL from http://mirror.centos.org/centos/7/os/x86_64/Packages/perl-local-lib-1.008010-4.el7.noarch.rpm
But that does not work either, so I can not figure out anything about the perl system the install.sh installed on a Base CENTOS7 from VULTR.
So, now I can not find the current installed perl modules from wherever it came from.
All I can do is perl -V which I leave here for you @
http://wwwc7.netstores.com/perlinstall
So, I am out of my normal element, and have not had to build everything from scratch or install from scratch.
Any help or suggestions will be appreciated. I have looked up and tried the normal way I am used to on how to find things but this OS install, is different the the CENTOS and CPanel install I am used to.
I have tried besides the perllocal method (which now does not work) as well as this:
perl -le âprint ls -lR $_ for @INCâ | more
which is not easily readable .
Any ideas how to get perllocal working so I can compare modules before I get lost in the weeds.?
perl-local-lib is not perllocal. Completely different tool. perllocal.pod is generated by CPAN installed packages, and we arenât using CPAN (though you could, if you did you should probably use a plenv or other local Perl environment manager).
You can see a list of Perl modules installed via the package manager with rpm -qa |grep perl- or probably a half dozen other incantations. perllocal.pod is not âlist all locally available perl modulesâ even though I understand thatâs what it kinda looks like, especially if everything was installed from source packages pulled from CPAN.
Thatâs because nothing about your cPanel system is CentOS. Theyâve made hacky versions of package management, among other things, that are unlike any other system. When youâre using cPanel you are using cPanel stuff; nobody else uses any of that stuff (well, perllocal is a normal Perl tool, though itâs not all that useful in modern environments, because mostly itâs recommended you use a plenv or perlbrew or similar tool when you need a heavily customized environment or newer perl or module versions that are in the system reposâŠperldoc perllocal will only find the modules installed via cpan in the environment youâre running it in). Perl modules installed via the system-standard package manager are not managed by cpan and are not listed in perllocal.pod.
2 Likes
Thanks Joe, I am beginning to understand the issues moving from CPanel.
Here is another one, now that I am testing the scripting function in the user directory.
Our system had 2 import mysql databases and tables.
So since you are not supporting CENTOS 8, and now Only CENTOS7 has apache working with scripting directories, the issue is mysql.
This version of installer on CENTOS 7 does not have mysql, and instead uses Mariadb, which is simlar, but I am getting an error from our admin session scripts that connect with DBII connect because I donât think the use
âCanât connect to local MySQL server through socket â/tmp/mysql.sockââ
Is that correct? there is no MySQL server /tmp socket on this virtualmin version on CENTOS?
Thatâs not accurate. We support CentOS 8, and it is usually the version of CentOS that I recommend.
I told you not to use it because you need suexec+CGI and making suexec+CGI work on CentOS 8 is tricky, and youâre having enough trouble making things work even without the added complexity of recompiling or using bind mounts or otherwise having to trick suexec into running apps in /home. Most people who prefer CentOS should use 8. Most people are not using suexec+CGI.
Joe:
I am not compaining to you, but I have expressed the needs that I have. Mysql tables, apache running in the manner I described. I am not knockn you, I just need the solution to work the way I need it to, not necessarily the way you think that most of your customers use, maybe a php app, or word press, of basic html. So, if you can point me to the correct direction of someone that can help me solve that with your control panel, that would be awesome.
Currently I run 2 Cpanel Servers, CENTOS 6, and whmcs, and Clustered DNS.
Anyone in your community that has the skills to do it.
Thanks
Joe:
Currently I completed 90% of the task to run the shopping cart software in 1 users directory creating another scripting bin. on PERL 5.16. I also was able to update most of the PERL modules needed for the application.
You can see few of the things to run the application. I have a couple of bugs still in the shopping cart from some old scripts, but in general, I was able to figure out most of the things and installing the necessary modules.
Here is an example of the Site As well as solving the mariadb mysql sock, that was just changing the port to 3306, and hardcoding the location of the mysql.sock file.
See link to login here
So once I solve some of the buggy issues, maybe we can find a way to make all the scripts system wide.