Reverse proxy subdomain to secondary application Nethserver

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!


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/ 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/ /etc/e-smith/templates-custom/etc/httpd/conf.d/

Now you can edit the copied file as needed.

At the end, use a

expand-template /etc/httpd/conf.d/

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_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.

1 Like

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


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'

1 Like

webtop5-webdav.conf comes from webtop5-webdav
webtop5-zpush.conf comes from webtop5-zpush

Indeed, this is the output of the command:

I checked at another NS which has webtop5 installed. The output there is:

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


yum install nethserver-webtop5


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.

 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:

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:

  1. 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”.

  2. 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

/usr/bin/rm -f /etc/httpd/conf.d/awstats.conf
/usr/bin/systemctl reload httpd
1 Like

A simplification to algorithm 2, so that no rpm has to be changed would be:

  1. The central template expansion code adds each generated file to a list (text file), let’s call it “template-generated-files”

  2. 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.

  3. When a nethserver package gets removed, follow it by an “yum autoremove” and “expland-and-cleanup-all-templates”.