repo-oss<\/code> repository, point firewalld at it, serve content from the SUSE document root, and host more than one site from a single server using vhosts.d<\/code>. We also test how the new enforcing SELinux policy treats nginx, because it does not behave the way the RHEL family does.<\/p>\n\nConfirmed working on openSUSE Leap 16.0 (nginx 1.27.2) in June 2026.<\/em><\/p>\n\nPrerequisites<\/h2>\n\n
nginx itself is light. What you size for is the traffic and the content it fronts. A static site or a reverse proxy in front of an app is happy on 1 vCPU and 1 GB of RAM; the moment nginx caches responses or terminates TLS at volume, RAM and CPU follow connection count and the size of your cache, not the nginx binary. For a real public site, start at 2 vCPU and 2 GB and watch worker_connections<\/code> and open file descriptors as the levers, then grow from there.<\/p>\n\n\n- A running openSUSE Leap 16 server with sudo access. The lab box here used 2 vCPU and 2 GB of RAM, which is a floor for following along, not a production recommendation.<\/li>\n
- A non-root user in the
wheel<\/code> group. If you have not done the base setup yet, work through the initial server setup and hardening<\/a> first.<\/li>\n- Network access to the openSUSE CDN so
zypper<\/code> can reach repo-oss<\/code>.<\/li>\n<\/ul>\n\nInstall nginx from the OSS repository<\/h2>\n\n
nginx lives in the default repo-oss<\/code> repository, so there is no third-party repo to add. Refresh the metadata and install the package:<\/p>\n\n\nsudo zypper refresh\nsudo zypper install nginx<\/code><\/pre>\n\n\nThe package pulls in a small set of Lua and module dependencies and creates a dedicated nginx<\/code> system user. Once it finishes, confirm the version. Here is the first Leap 16 quirk: the nginx<\/code> binary lives in \/usr\/sbin<\/code>, which is not on a normal user’s PATH<\/code>, so call it through sudo or by full path:<\/p>\n\n\nsudo nginx -v<\/code><\/pre>\n\n\nThe version prints on stderr:<\/p>\n\n\n
nginx version: nginx\/1.27.2<\/code><\/pre>\n\n\nStart nginx and enable it at boot<\/h2>\n\n
The package does not start the service for you. Enable and start it in one step so it survives a reboot:<\/p>\n\n\n
sudo systemctl enable --now nginx<\/code><\/pre>\n\n\nCheck that systemd reports it active:<\/p>\n\n\n
systemctl status nginx --no-pager<\/code><\/pre>\n\n\nThe status line should read active (running)<\/code>, and you will see that systemd runs an nginx -t<\/code> config test before every start:<\/p>\n\n\n\u25cf nginx.service - The nginx HTTP and reverse proxy server\n Loaded: loaded (\/usr\/lib\/systemd\/system\/nginx.service; enabled; preset: disabled)\n Active: active (running) since Fri 2026-06-19 01:01:58 CEST; 13ms ago\n Process: 3875 ExecStartPre=\/usr\/sbin\/nginx -t (code=exited, status=0\/SUCCESS)\n Main PID: 3878 ((nginx))<\/code><\/pre>\n\n\nOpen the firewall<\/h2>\n\n
Leap 16 runs firewalld, and the default zone blocks inbound HTTP and HTTPS. Add both services and reload so nginx is reachable from the network:<\/p>\n\n\n
sudo firewall-cmd --permanent --add-service=http\nsudo firewall-cmd --permanent --add-service=https\nsudo firewall-cmd --reload<\/code><\/pre>\n\n\nConfirm both services are now allowed in the active zone:<\/p>\n\n\n
sudo firewall-cmd --list-services<\/code><\/pre>\n\n\nYou should see http<\/code> and https<\/code> alongside ssh<\/code> and cockpit<\/code>:<\/p>\n\n\ncockpit dhcpv6-client http https ssh<\/code><\/pre>\n\n\nServe the first page from the SUSE document root<\/h2>\n\n
This is where openSUSE differs from almost every other distro. The default document root is \/srv\/www\/htdocs\/<\/code><\/strong>, not \/var\/www\/html<\/code> or \/usr\/share\/nginx\/html<\/code>. By default that directory only holds a 50x.html<\/code> error page, so a fresh install answers with a blunt 403 Forbidden<\/code> until you give it an index file:<\/p>\n\n\ncurl -I http:\/\/localhost<\/code><\/pre>\n\n\nBefore you add content, that request returns:<\/p>\n\n\n
HTTP\/1.1 403 Forbidden\nServer: nginx\/1.27.2<\/code><\/pre>\n\n\nDrop an index page into the document root and the 403 turns into a 200:<\/p>\n\n\n
echo '<h1>nginx is running on openSUSE Leap 16<\/h1>' | sudo tee \/srv\/www\/htdocs\/index.html<\/code><\/pre>\n\n\nRequest it again and nginx serves the file:<\/p>\n\n\n
curl -I http:\/\/localhost<\/code><\/pre>\n\n\nThe status is now 200 OK<\/code>. Point a browser at the server’s IP address and you get the page back.<\/p>\n\n\n![\"nginx](\"https:\/\/computingforgeeks.com\/wp-content\/uploads\/2026\/06\/wm-nginx-welcome-page-opensuse-leap.png\" "\\"\\"")
<\/figure>\n\n\nHost multiple sites with name-based virtual hosts<\/h2>\n\n
nginx on Leap 16 reads extra server blocks from \/etc\/nginx\/vhosts.d\/<\/code>. The main nginx.conf<\/code> already pulls them in with include vhosts.d\/*.conf;<\/code>, so you never edit the shipped config to add a site. Each site gets its own file.<\/p>\n\nBecause the same hostname and web root repeat across several commands, set them once as shell variables and reuse them. Change the two values to match your real domain:<\/p>\n\n\n
export SITE_DOMAIN=\"example.com\"\nexport WEB_ROOT=\"\/srv\/www\/vhosts\/${SITE_DOMAIN}\"<\/code><\/pre>\n\n\nCreate the document root for the site and give it a landing page:<\/p>\n\n\n
sudo mkdir -p \"${WEB_ROOT}\"\necho \"<h1>${SITE_DOMAIN} served by nginx on Leap 16<\/h1>\" | sudo tee \"${WEB_ROOT}\/index.html\"<\/code><\/pre>\n\n\nNow write the server block. Open a new file under vhosts.d<\/code>:<\/p>\n\n\nsudo vim \/etc\/nginx\/vhosts.d\/example.com.conf<\/code><\/pre>\n\n\nAdd the following, keeping the paths in line with the variables you set above:<\/p>\n\n\n
server {\n listen 80;\n server_name example.com www.example.com;\n root \/srv\/www\/vhosts\/example.com;\n index index.html;\n\n access_log \/var\/log\/nginx\/example.com-access.log;\n error_log \/var\/log\/nginx\/example.com-error.log;\n}<\/code><\/pre>\n\n\nTest the configuration before reloading. nginx -t<\/code> catches a stray semicolon or a bad path before it can take the service down:<\/p>\n\n\nsudo nginx -t<\/code><\/pre>\n\n\nA clean config reports both lines as successful:<\/p>\n\n\n
nginx: the configuration file \/etc\/nginx\/nginx.conf syntax is ok\nnginx: configuration file \/etc\/nginx\/nginx.conf test is successful<\/code><\/pre>\n\n\nReload to apply the new site without dropping existing connections:<\/p>\n\n\n
sudo systemctl reload nginx<\/code><\/pre>\n\n\nYou can prove the virtual host answers for its name by sending a matching Host<\/code> header, which is what a browser does when it resolves the domain:<\/p>\n\n\ncurl -s -H \"Host: ${SITE_DOMAIN}\" http:\/\/127.0.0.1\/<\/code><\/pre>\n\n\nnginx returns the virtual host’s page rather than the default document root:<\/p>\n\n\n
<h1>example.com served by nginx on Leap 16<\/h1><\/code><\/pre>\n\n\nHow SELinux treats nginx on Leap 16<\/h2>\n\n
Leap 16 is the first openSUSE release to ship SELinux in enforcing mode by default, so it is worth knowing exactly how strict it is with a web server. Check the process domain and you will see nginx runs confined as httpd_t<\/code>, the same domain the RHEL family uses:<\/p>\n\n\nps -eZ | grep nginx<\/code><\/pre>\n\n\nEach worker carries the confined label:<\/p>\n\n\n
system_u:system_r:httpd_t:s0 3878 ? 00:00:00 nginx<\/code><\/pre>\n\n\nHere is the part that surprises anyone coming from Rocky or RHEL. We placed a document root outside the standard tree, at \/opt\/mysite<\/code> with the generic usr_t<\/code> label, pointed a server block at it, and requested it. On RHEL that earns an instant AVC denial. On this Leap 16 install the request returned 200 OK<\/code> with no denial in the audit log. The reason becomes clear when you list the tunable SELinux booleans:<\/p>\n\n\ngetsebool -a<\/code><\/pre>\n\n\nOn this release that command returns an empty list. There are none of the httpd_*<\/code> toggles you would flip on RHEL, because the targeted policy shipped with Leap 16 does not constrain the web server’s file access the way the RHEL policy does. In practice that means you will not fight SELinux over document-root labels here, but treat it as how this release behaves rather than a permanent guarantee. Keep document roots under \/srv\/www<\/code> as the clean habit, and if a future policy update tightens things, relabel a custom path the standard way:<\/p>\n\n\nsudo semanage fcontext -a -t httpd_sys_content_t \"\/opt\/mysite(\/.*)?\"\nsudo restorecon -Rv \/opt\/mysite<\/code><\/pre>\n\n\nThat keeps your layout portable if you ever move the site to a stricter distro.<\/p>\n\n\n![\"nginx](\"https:\/\/computingforgeeks.com\/wp-content\/uploads\/2026\/06\/wm-nginx-version-status-opensuse-leap.png\" "\\"\\"")
<\/figure>\n\n\nTroubleshooting the first run<\/h2>\n\n
Three errors account for almost every failed first start on Leap 16, and all three have quick fixes.<\/p>\n\n
nginx: command not found<\/h3>\n\n
Running nginx -v<\/code> as your normal user fails because the binary is in \/usr\/sbin<\/code>. Call it with sudo nginx -v<\/code> or the full path \/usr\/sbin\/nginx -v<\/code>. The service itself is unaffected; this only bites interactive commands.<\/p>\n\n403 Forbidden on a brand new install<\/h3>\n\n
A fresh document root has no index.html<\/code>, so nginx has nothing to return and answers 403 Forbidden<\/code>. Add an index file to \/srv\/www\/htdocs\/<\/code> (or your virtual host root) and the error clears. This is expected behavior, not a broken install.<\/p>\n\nThe site loads but ignores your server block<\/h3>\n\n
If a virtual host serves the default page instead of its own, the usual cause is that systemctl reload nginx<\/code> was skipped after editing the file, or server_name<\/code> does not match the host you requested. Run sudo nginx -t<\/code> to confirm the file parsed, reload, and verify with the curl -H \"Host: ${SITE_DOMAIN}\"<\/code> check above. With the config valid and reloaded, nginx routes the request to the right block end to end.<\/p>\n\nFrom here nginx is ready to front real applications. The natural next step is to put it behind a Let’s Encrypt certificate<\/a> so it serves HTTPS, or to place it in front of a container workload from the Docker and Podman setup<\/a>, or to manage the service and watch its logs from the browser using Cockpit, the YaST replacement<\/a>. If you are still settling into the distro, the things to do after installing Leap 16<\/a> guide and the zypper command reference<\/a> cover the groundwork around this setup.<\/p>\n","protected":false},"excerpt":{"rendered":"A web server is only useful once three pieces line up: the nginx package, the firewall that lets traffic reach it, and the document root it serves. On openSUSE Leap 16 those pieces sit in slightly different places than they do on a Debian or RHEL box, and Leap 16 ships SELinux in enforcing mode … Read more<\/a><\/p>\n","protected":false},"author":9,"featured_media":169165,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[299,47,50,349],"tags":[282,177,9986,21787],"cfg_series":[39887],"class_list":["post-169166","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-how-to","category-linux","category-linux-tutorials","category-web-hosting","tag-linux","tag-nginx","tag-opensuse","tag-web-server","cfg_series-opensuse-leap-16"],"_links":{"self":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/169166","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/comments?post=169166"}],"version-history":[{"count":1,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/169166\/revisions"}],"predecessor-version":[{"id":169220,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/169166\/revisions\/169220"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/media\/169165"}],"wp:attachment":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/media?parent=169166"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/categories?post=169166"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/tags?post=169166"},{"taxonomy":"cfg_series","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/cfg_series?post=169166"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}