Unable to restore teleporter backup - fresh install, no funky changes made

Expected Behavior:

  • DietPi v7.9.3
  • Raspi Model 3B+
  • Fresh image to which I installed Pi-hole and Unbound

That I would be able to restore a teleporter backup so that I may use my blocklists (after I re-imaged my SD card)

Actual Behaviour:

After browsing to the file via the web interface then selecting restore a modal pops up with a small spinning dial. After about 30seconds it displays the text seen below. This behavior was observed in Edge and Firefox (both updated in the last month).

Output of the console in edge was: Refused to display 'http://192.168.1.2/' in a frame because it set 'X-Frame-Options' to 'deny'. and I got the same deny response header in Firefox

How would I go about fixing this so that I can successfully restore my backup?

Debug Token:

I have privatebin that I can PM on request (I've cut out things that might identify who I am)

Please post the token or PM the log. The token is only accessible to a handful of people (moderators and devs and auto-deleted after 48h)

Hey mate, will PM it in the morning - apologies I didn’t see this sooner, the notifications got auto put in promotions folder on my email..

This is your lighttpd.conf

-rw-r--r-- 1 root root 2.2K Dec 12 19:55 /etc/lighttpd/lighttpd.conf
   server.modules = (
   	"mod_indexfile",
   	"mod_setenv",
   	"mod_access",
   	"mod_alias",
    	"mod_redirect",
   )
   server.document-root = "/var/www"
   server.upload-dirs          = ( "/var/cache/lighttpd/uploads" )
   server.errorlog             = "/var/log/lighttpd/error.log"
   server.pid-file             = "/run/lighttpd.pid"
   server.username             = "www-data"
   server.groupname            = "www-data"
   server.port                 = 80
   server.feature-flags       += ("server.h2proto" => "enable")
   server.feature-flags       += ("server.h2c"     => "enable")
   server.feature-flags       += ("server.graceful-shutdown-timeout" => 5)
   server.http-parseopts = (
     "header-strict"           => "enable",# default
     "host-strict"             => "enable",# default
     "host-normalize"          => "enable",# default
     "url-normalize-unreserved"=> "enable",# recommended highly
     "url-normalize-required"  => "enable",# recommended
     "url-ctrls-reject"        => "enable",# recommended
     "url-path-2f-decode"      => "enable",# recommended highly (unless breaks app)
     "url-path-dotseg-remove"  => "enable",# recommended highly (unless breaks app)
   )
   index-file.names            = ( "index.php", "index.html" )
   url.access-deny             = ( "~", ".inc" )
   static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
   include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
   include_shell "/usr/share/lighttpd/create-mime.conf.pl"
   include "/etc/lighttpd/conf-enabled/*.conf"
   server.modules += (
   	"mod_dirlisting",
   	"mod_staticfile",
   )

What is missing is

# allow teleporter iframe on settings page
$HTTP["url"] =~ "/teleporter\.php$" {
    $HTTP["referer"] =~ "/admin/settings\.php" {
        setenv.add-response-header = ( "X-Frame-Options" => "SAMEORIGIN" )
    }
}

Added by Companion to pi-hole/adminlte #1231 by PromoFaux · Pull Request #4375 · pi-hole/pi-hole · GitHub.

You're running the latest version, so this should included in your lighttpd.conf

*** [ DIAGNOSING ]: Core version
[i] Core: v5.6 (https://discourse.pi-hole.net/t/how-do-i-update-pi-hole/249)
[i] Remotes: origin	https://github.com/pi-hole/pi-hole.git (fetch)
             origin	https://github.com/pi-hole/pi-hole.git (push)
[i] Branch: master
[i] Commit: v5.6-0-gb5e0f14

*** [ DIAGNOSING ]: Web version
[i] Web: v5.8 (https://discourse.pi-hole.net/t/how-do-i-update-pi-hole/249)
[i] Remotes: origin	https://github.com/pi-hole/AdminLTE.git (fetch)
             origin	https://github.com/pi-hole/AdminLTE.git (push)
[i] Branch: master
[i] Commit: v5.8-0-gee50954

*** [ DIAGNOSING ]: FTL version
[✓] FTL: v5.11

As you're running Diet Pi, I'm pinging @MichaIng as there might be some modifications to the conf file.

Side note: your systems date seems off

[i] 2021-12-12:21:26:56 debug log has been initialized.

2 Likes

Many thanks guys, I try to watch Pi-hole development closely but that one we obviously missed. Just fixed for next release: v8.0 · MichaIng/DietPi@cd3ac38 · GitHub

Do the following to fix it now:

curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.conf/dps_93/lighttpd.pihole.conf' -o /etc/lighttpd/conf-available/99-dietpi-pihole.conf
systemctl restart lighttpd

Nginx was as always a pain due to the fact that it does not inherit anything from parent location directives :confounded:, took a while until I remembered that :sweat_smile:.
EDIT: Another fix for Nginx, now it really sets DENY when requested from anywhere else: v8.0 · MichaIng/DietPi@81aee17 · GitHub

2 Likes

You might also want to keep an eye on Companion to pi-hole/adminlte #1996 by yubiuser · Pull Request #4461 · pi-hole/pi-hole · GitHub

1 Like

Thanks, I'll add it the same way, can be also merged by expanding the location regex for teleporter.php.

EDIT: Implemented: v8.0 · MichaIng/DietPi@9605674 · GitHub

@MichaIng Hi mate, I've gone and attempted to run it under root, however from the looks of it, the command did not work:

rootuser@DietPi:~# curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/ .conf/dps_93/lighttpd.pihole.conf' -o /etc/lighttpd/conf-available/99-dietpi-pih ole.conf
systemctl restart lighttpd
rootuser@DietPi:~# ^C
rootuser@DietPi:~# sudo reboot

After attempting to apply it and then reboot to be safe - I tried restoring again and got the same result. My apologies if I have done something exceedingly stupid re: command

Also in the future would it be better for me to post issues in the DietPi github given from what has been said here, pihole seems to have some modifications to it for Diet-Pi? (Initially I thought it was just stock standard which is why I came here)

While the error looks different (Edge vs Firefox?), the content still indicates that it is denied by the X-Frame-Options header. The browser console verifies this, right? Strange, I just tested successfully with a fresh install this config. Since I updated it two times, can you paste the content of it?

cat /etc/lighttpd/conf-available/99-dietpi-pih ole.conf

Are you running a Buster or Bullseye image? I tested with the latter but will redo with the first, to be sure. Though only basic syntax is used, no fancy new modules or so :thinking:.

Also in the future would it be better for me to post issues in the DietPi github given from what has been said here, pihole seems to have some modifications to it for Diet-Pi? (Initially I thought it was just stock standard which is why I came here)

The Pi-hole core (+AdminLTE) installation is the same (aside of reduced default long-term query log time), using the official installer. But the webserver configuration is different, skipped in the Pi-hole installer via --disable-install-webserver flag: DietPi installs the webserver for multiple possible web applications, so a generic default config and application specific configs only applied for each applications sub directories. That way you can also install Pi-hole with Nginx and Apache2 webservers. So yes this means when it is issues with the web interface, you can report on our GitHub, so we can try to find out whether it is due to our webserver config or an upstream issue, and forward in case. Here on the forum you can also use the dietpi tag so I get a mail notification.

EDIT: Works as well on Buster fine here :thinking:.
A way to verify whether the correct header is returned:

curl -I http://localhost/admin/scripts/php/teleporter.php

should contain X-Frame-Options: DENY. But:

curl -Ie '/admin/settings.php' http://localhost/admin/scripts/php/teleporter.php

should contain X-Frame-Options: SAMEORIGIN.

Its definitely bullseye and v7.9.2

Output of the commands you asked me to run:

rootuser@DietPi:~# cat /etc/lighttpd/conf-available/99-dietpi-pih ole.conf
cat: /etc/lighttpd/conf-available/99-dietpi-pih: No such file or directory
cat: ole.conf: No such file or directory
rootuser@DietPi:~# ^C
rootuser@DietPi:~# curl -I http://localhost/admin/scripts/php/teleporter.php
HTTP/1.1 404 Not Found
Content-Type: text/html
X-Pi-hole: The Pi-hole Web interface is working!
X-Frame-Options: DENY
Content-Length: 341
Date: Fri, 17 Dec 2021 00:36:16 GMT
Server: lighttpd/1.4.59

rootuser@DietPi:~# curl -Ie '/admin/settings.php' http://localhost/admin/scripts/php /teleporter.php
HTTP/1.1 404 Not Found
Content-Type: text/html
X-Frame-Options: SAMEORIGIN
Content-Length: 341
Date: Fri, 17 Dec 2021 00:36:37 GMT
Server: lighttpd/1.4.59

rootuser@DietPi:~#

It works on I.E at least

I.E works (My apologies I failed to test it in my prior comment as I got the same error in Firefox so I assumed)

Firefox fails (Could it be some config of mine?)


Oh, there was an unintended space in the command above:

cat /etc/lighttpd/conf-available/99-dietpi-pihole.conf

However based on curl it works as expected. About the reponse headers in Firefox, I think this is the one for the GET .../api.php?getCacheinfo= request, while we are looking for a POST request to teleporter.php. Probably it is Firefox or some configs it has which treats iframes more strictly. I'll test.

Here we go :grinning:

Also just so you know, I have successfully restored via firefox in the past, I've not changed my user.js since then.

# Based on: https://github.com/pi-hole/pi-hole/blob/a3cc5df317ffeec2b6bf78d37e075f33aeb0f79c/advanced/lighttpd.conf.debian

# Admin panel
$HTTP["url"] =~ "^(/html)?/admin/" {
        # Create response header for Pi-hole debugger
        setenv.add-response-header = (
                "X-Pi-hole" => "The Pi-hole Web interface is working!",
                "X-Frame-Options" => "DENY"
        )

        # Allow teleporter and API QR code iframes on settings page
        $HTTP["url"] =~ "/(teleporter|api_token)\.php$" {
                $HTTP["referer"] =~ "/admin/settings\.php" {
                        setenv.add-response-header = ( "X-Frame-Options" => "SAMEORIGIN" )
                }
        }
}

# Block . files from being served, such as .git, .github, .gitignore
$HTTP["url"] =~ "^(/html)?/admin/\." {
        url.access-deny = ("")
}

# Block public access to 404 page
$HTTP["url"] =~ "^(/html)?/pihole/" {
        $HTTP["remoteip"] !~ "^(1(27|92\.168|0|72\.(1[6-9]|2[0-9]|3[0-1]))\.|::1|fe[89ab].:|f[cd]..:)" {
                url.access-deny = ("")
        }
}```

Do you have a chance to test it with a clean Firefox? Also assure to clear the browser cache, and probably all cookies/browser data for to the Pi-hole page. I tested it with Opera, Brave, Edge and Firefox (95.0.1), and enabled strictest possible settings in Firefox, and it works fine on all of them. Since the correct header is returned, it is at least not a server issue anymore.

Completely wiping the profile allowed it to succeed on Firefox :thinking: Guess I have another night of troubleshooting myself this weekend :rofl:

Thank you very much both @MichaIng and @yubiuser

I will mark the answer that fixed this as the solution too :wink:

1 Like

All good, I'm glad you brought up this topic so that we were able to update our Pi-hole webserver configs for this and future needs. There were also other little enhancements, like a removed obsolete header and IPv6 client access to the blocking/404 page.

Still not sure why Firefox may have still blocked it: While the teleporter.php request does not return any caching headers (to actively disable browser caching), the mime type text/html, especially in combination with an .php extension is nothing a browser should and would cache by default. If you face the same again, maybe you are able to identify the settings change related to it or whether clearing browser data for that page works. It may then help other Firefox users or even us to mitigate it in the first place :slightly_smiling_face:.

It could well be the user.js script I have interacting with it in ways it did not previously- I’ll let you know more if I discover anything that is not PEBCAK on that front :sweat_smile:

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.