Sry, as I don’t use Webtop myself, I can’t give any tips, but I’m sure one of the Webtop devs can help…
Nextcloud: If the virtualhost is checked, it will ONLY be available under that name…
Even IP/nextcloud will NOT work!
Andy
Sry, as I don’t use Webtop myself, I can’t give any tips, but I’m sure one of the Webtop devs can help…
Nextcloud: If the virtualhost is checked, it will ONLY be available under that name…
Even IP/nextcloud will NOT work!
Andy
I found the reason for problem 1 myself: The problem is, that the /etc/httpd/conf.d/ already contained three reverse proxy files for webtop although webtop is NOT installied on this machine. These make it impossible to reverse proxy an domain contaning /webtop in the path. Removing this files solved the problem (temporarily).
The files are webtop5-webdav.conf, webtop5-zpush.conf, webtop.conf.
I think either these files should only be installied/aktivated, when webtop gets installed. In addition the configured reverse proxy domains should take precedence over other configuration especially those with ProxyPass.
The question is now: How to disable it without having the next update break the configuration.
In the destination server I had to comment out the redirection from http to https in file conf.d/default-virtualhost.inc because the SSL is done by the front reverse proxy server.
#
# 20webtop
#
#RewriteEngine on
#RewriteRule ^/webtop(/.*)?$ https://%{SERVER_NAME}/webtop$1 [L,R=301]
#
# 40nextcloud
#
#RewriteEngine On
#RewriteCond %{HTTPS} !=on
#RewriteRule ^/nextcloud(/.*)?$ https://%{HTTP_HOST}/nextcloud$1 [L,R=301]
But this change will be overridden by updates. How to make this change permanent? Or maybe is there a UI setting?
Hallo Carsten
Make a custom template on the destination server to keep your config changes update-proof…
Note: Templates-Custom take precedence over Templates.
You will find the existing templates under /etc/e-smith/templates/etc/httpd/conf.d
Create under /etc/e-smith/templates-custom the same structure as above:
mkdir /etc/e-smith/templates-custom/etc
mkdir /etc/e-smith/templates-custom/etc/httpd
mkdir /etc/e-smith/templates-custom/etc/httpd/conf.d
Copy over the original code / template:
cp /etc/e-smith/templates/etc/httpd/conf.d/default-virtualhost.inc /etc/e-smith/templates-custom/etc/httpd/conf.d/default-virtualhost.inc
Now you can edit the copied file as needed.
At the end, use a
expand-template /etc/httpd/conf.d/default-virtualhost.inc
and maybe a restart of httpd
systemctl restart httpd
Check the real config file, if your changes are now persistant, they should be!
Good Luck!
My 2 cents
Andy
@Andy_Wismer Thanks a lot.
It would be nice, if the disabling of SSL enforcement would be available in the UI in the future. Perhaps someone wil do it.
I found a simpler solution. Just proxy to https instead of http (which is not working currently). This removes the need to change existing templates. However, the files webtop5-webdav.conf, webtop5-zpush.conf, webtop.conf still have to be removed, because the take precedence over the reverse proxy configuration.
Also I improved the reverse proxy to handle WebSockets automatically.
Trying to understand what is your concerns but these files are not present on my email server, and it is good because I do not use webtop
so now I would like to understand where come these files
so
rpm -qf /path/to/the/files
My best bet is that you have installed nethserver-webtop5 then removed it but you have not removed the last dependencies
please check
rpm -qa | grep -i 'webtop'
webtop5-webdav.conf comes from webtop5-webdav
webtop5-zpush.conf comes from webtop5-zpush
Indeed, this is the output of the command:
webtop5-zpush-1.2.1-1.ns7.noarch
webtop5-webdav-0.3.0-1.ns7.noarch
webtop5-1.4.7-1.ns7.noarch
I checked at another NS which has webtop5 installed. The output there is:
webtop5-1.4.7-1.ns7.noarch
webtop5-zpush-1.2.1-1.ns7.noarch
nethserver-webtop5-1.6.3-1.ns7.noarch
webtop5-webdav-0.3.0-1.ns7.noarch
So removing webtop5 from with the “Remove” command from the applications dashboard does a partial uninstall only. Could this be improved so that NS deinstalls all packages of an application when it gets removed?
to remove all unnecessary dependencies do
yum autoremove
this is the normal
way of yum, maybe not your normal
way of thought I assume
Try yourself in a VM
do
yum install nethserver-webtop5
then
yum remove nethserver-webtop5
only nethserver-webtop5
is removed
Morover templates are not removed when the nethserver-xxxx is removed, that could hurt badly I think.
The easy way could use a %postun
in the rpm and clean up all templates, but I think no developers have made it…at least I have never read something related to templates removal in a rpm spec.
The httpd case is specific because httpd is always running, not like another services that we could uninstall or stop. Maybe we have a room for improvements here
I don’t suggest to automatically remove templates or settings during package removal?
Now modules can be uninstalled… why don’t realize two toggles (one for settings, one for custom templates?)
What about “yum autoremove”. In theory this should remove all packages which where installed only because of a dependency of others, but are not longer referenced.
I just issued the command in one of my server and it suggests quite many packages for removal. Do you think it is save to say “Yes”? to them? If yum autoremove is save, then it should be considered to issue this command at package removal. This should also remove templates.
Removing:
fann x86_64 2.2.0-6.el7 @epel 349 k
ghostscript x86_64 9.25-2.el7_7.3 @ce-updates 150 k
ghostscript-fonts noarch 5.50-32.el7 @ce-base 622 k
nethserver-rh-php71-php-fpm noarch 1.1.2-1.ns7 @nethserver-updates 206
openblas-serial x86_64 0.3.3-2.el7 @epel 35 M
php-imap x86_64 5.4.16-9.el7 @epel 105 k
php-ldap x86_64 5.4.16-48.el7 @ce-base 57 k
php-mbstring x86_64 5.4.16-48.el7 @ce-base 1.3 M
php-mcrypt x86_64 5.4.16-9.el7 @epel 48 k
php-process x86_64 5.4.16-48.el7 @ce-base 78 k
poppler-data noarch 0.4.6-3.el7 @ce-base 11 M
python2-gflags noarch 2.0-5.el7 @epel 328 k
sclo-php71-php-imap x86_64 7.1.30-1.el7 @ce-sclo-sclo 100 k
sclo-php71-php-mcrypt x86_64 7.1.30-1.el7 @ce-sclo-sclo 47 k
sclo-php71-php-smbclient x86_64 1.0.0-1.el7 @ce-sclo-sclo 98 k
sclo-php71-php-tidy x86_64 7.1.30-1.el7 @ce-sclo-sclo 415 k
sclo-php72-php-pecl-imagick x86_64 3.4.4-3.el7 @ce-sclo-sclo 506 k
sclo-php72-php-smbclient x86_64 1.0.0-1.el7 @ce-sclo-sclo 98 k
Removing for dependencies:
libgfortran x86_64 4.8.5-39.el7 @ce-base 1.1 M
libmcrypt x86_64 2.5.8-13.el7 @epel 283 k
libquadmath x86_64 4.8.5-39.el7 @ce-base 276 k
rh-php71 x86_64 1-1.el7 @ce-sclo-rh 0.0
rh-php71-php-bcmath x86_64 7.1.30-2.el7 @ce-sclo-rh 58 k
rh-php71-php-cli x86_64 7.1.30-2.el7 @ce-sclo-rh 8.4 M
rh-php71-php-common x86_64 7.1.30-2.el7 @ce-sclo-rh 4.5 M
rh-php71-php-enchant x86_64 7.1.30-2.el7 @ce-sclo-rh 25 k
rh-php71-php-fpm x86_64 7.1.30-2.el7 @ce-sclo-rh 4.3 M
rh-php71-php-gd x86_64 7.1.30-2.el7 @ce-sclo-rh 375 k
rh-php71-php-intl x86_64 7.1.30-2.el7 @ce-sclo-rh 465 k
rh-php71-php-json x86_64 7.1.30-2.el7 @ce-sclo-rh 40 k
rh-php71-php-ldap x86_64 7.1.30-2.el7 @ce-sclo-rh 65 k
rh-php71-php-mbstring x86_64 7.1.30-2.el7 @ce-sclo-rh 1.4 M
rh-php71-php-mysqlnd x86_64 7.1.30-2.el7 @ce-sclo-rh 419 k
rh-php71-php-opcache x86_64 7.1.30-2.el7 @ce-sclo-rh 395 k
rh-php71-php-pdo x86_64 7.1.30-2.el7 @ce-sclo-rh 189 k
rh-php71-php-pear noarch 1:1.10.4-1.el7 @ce-sclo-rh 2.1 M
rh-php71-php-pecl-apcu x86_64 5.1.8-1.el7 @ce-sclo-rh 177 k
rh-php71-php-pgsql x86_64 7.1.30-2.el7 @ce-sclo-rh 183 k
rh-php71-php-process x86_64 7.1.30-2.el7 @ce-sclo-rh 90 k
rh-php71-php-soap x86_64 7.1.30-2.el7 @ce-sclo-rh 308 k
rh-php71-php-xml x86_64 7.1.30-2.el7 @ce-sclo-rh 427 k
rh-php71-php-zip x86_64 7.1.30-2.el7 @ce-sclo-rh 136 k
rh-php71-runtime x86_64 1-1.el7 @ce-sclo-rh 22 k
At another server the list was only one package:
python2-gflags-2.0-5.el7.noarch
In theory yes, rh-php71 has been removed as dependencies from another rpm, probably nextcloud IIRC
No, you cannot mix dependencies removal which come from yum and templates removal that it comes from esmith::templates.
The answer cannot be simple, either each developers takes care to remove template of httpd, or we provide a way to remove all templates, but in any ways, all rpm must be analysed and provide a way to remove all its templates.
As I said, it concerns only httpd, because in most of all cases the service is stopped after you remove the nethserver-xxxx rpm
Are the templates not also just files in /etc/e-smith which get installed by the package? Then they would be removed also by the package removal.
By what other means are the template files created instead?
these are removed yes, but the template expansion in the real folder no
for example
/etc/e-smith/templates/etc/httpd/conf.d/webtop.conf/10base will be removed
but the expansion /etc/httpd/conf.d/webtop.conf will stay in the httpd folder and this could break your apache configuration
Ok. It should be possible to automatically remove all these configurations. One algorithm would be:
Build a list of packages which are also removed by the specific nethserver package. Either do it upfront or do it incrementely package by package later by querying the list of “yum autoremove”.
Before removal of a package, check which template files are defined by the installed package. Then remove the package and check again. If there is another package installed which has a template part for the same file, trigger the template expansion to regenerate the destination file otherwise remove the destination file. (have a command “yum-ns-remove” which is used instead of “yum remove”)
Algorithm 2:
Another possibility would be to have an post action for package installed which records the list of files generated by templates in separate file. This list would contain template generated destinations. If someone remove some packages with yum, you can afterwards start a ns-template-cleanup, which does similar checks as in point 2 above, i.e. check whether a former template generated file still has a template in the installed packages, then issue a template-expansion otherweise delete the file. In any case remove the file from the list of template generated files.
started to implement a %postun in my rpm
%postun
/usr/bin/rm -f /etc/httpd/conf.d/awstats.conf
/usr/bin/systemctl reload httpd
A simplification to algorithm 2, so that no rpm has to be changed would be:
The central template expansion code adds each generated file to a list (text file), let’s call it “template-generated-files”
Have a “expand-and-cleanup-all-templates” command, which simply expands all existing templates and removes all files listed in the “template-generate-file” list above from the system (and the “template-generate-file” list), which are not regenerated.
When a nethserver package gets removed, follow it by an “yum autoremove” and “expland-and-cleanup-all-templates”.