Package Details: pi-hole-server 5.18.3-4

Git Clone URL: https://aur.archlinux.org/pi-hole-server.git (read-only, click to copy)
Package Base: pi-hole-server
Description: The Pi-hole is an advertising-aware DNS/Web server. Arch adaptation for lan wide DNS server.
Upstream URL: https://github.com/pi-hole/pi-hole
Keywords: ad block pi-hole
Licenses: EUPL-1.2
Conflicts: pi-hole-standalone
Submitter: max.bra
Maintainer: max.bra (graysky)
Last Packager: max.bra
Votes: 112
Popularity: 0.134716
First Submitted: 2016-01-13 12:50 (UTC)
Last Updated: 2024-08-10 12:32 (UTC)

Dependencies (18)

Required by (2)

Sources (15)

Pinned Comments

max.bra commented on 2018-02-09 16:45 (UTC) (edited on 2019-10-18 23:14 (UTC) by max.bra)

ArchLinux Pi-hole is not officially supported by Pi-hole project. In case of bugs and malfunctions please DO NOT file a report upstream.

First of all check if the wiki (https://wiki.archlinux.org/index.php/Pi-hole) can help then ask here for assistance and tips.
When it will be excluded that the problem does not depend on ArchLinux we will file a bug upstream.

Latest Comments

« First ‹ Previous 1 .. 32 33 34 35 36 37 38 39 40 41 42 .. 82 Next › Last »

max.bra commented on 2019-10-16 15:32 (UTC)

hi alephZer0, please check the first pinned comment on this page.

If it's not your case, can you pastebin (or any other service) this?

    ls -l /etc/pihole

Prakkie commented on 2019-10-16 15:29 (UTC)

@alephZero, did you happen to check pinned comment and try?

Checking /etc/shadow, the user http had a trailing 1:

$ sudo cat /etc/shadow | grep http http:!!:18174::::::1: Removing the expiration date has resolved it:

$ sudo chage --expiredate -1 http

max.bra commented on 2019-10-16 15:28 (UTC) (edited on 2019-10-17 06:18 (UTC) by max.bra)

Since switching to pihole user for pihole-FTL - long term data is not retained on my machine.

sir_randomuser said: For some reason account http has expired, which was the root cause. Seems to be due to a recent systemd change: https://bugs.archlinux.org/task/63704
Checking /etc/shadow, the user http had a trailing 1:

$ sudo cat /etc/shadow | grep http
http:!!:18174::::::1:

Removing the expiration date has resolved it:

$ sudo chage --expiredate -1 http

denisse commented on 2019-10-16 15:19 (UTC)

I'm sadly unable to save settings for my Pi Hole using the web interface.

The web interface gives me a message saying that everything was saved buy when I reload, nothing was saved.

The Pi Hole is working in the sense that it's blocking ads, but I want to use it a my DHCP server but I'm unable to do it as the setting is not saved.

Could you please give me a hand?

Prakkie commented on 2019-10-15 22:35 (UTC)

wonderful @max.bra. It works now. GREAT THANKS.

max.bra commented on 2019-10-15 21:50 (UTC)

hi Prakkie, read the first pinned comment on https://aur.archlinux.org/packages/pi-hole-ftl/ page.

Prakkie commented on 2019-10-15 21:05 (UTC)

pihole on arch - webui shows status as unknown

After upgrading to latest arch with linux version 5.3.6, pihole web UI comes with status as "Unknown" and "Enable" button. When i click on enable button, status becomes "Active" however its not persistent. The moment i click on any other option in webui, status goes back to "Unknown".

I am not sure what i am missing. pihole -d is not available in arch. CLI shows pihole is active. I am not finding any errors in nginx logs too.

I followed instructions in arch pihole page. I tried both nginx as well as lighttpd.

graysky commented on 2019-09-25 20:46 (UTC) (edited on 2019-09-25 20:47 (UTC) by graysky)

I think the issue is that @max.bra has created the same name of the patches but has modified them since doing so. Therefore, if a user built an older version expecting the patch, the checksums would be different. One solution is to append a date to the patch itself in the source array as suggested below, another is to use use a tag in the github repo.

tag=v6.35
git tag $tag -m "$tag" && git push --tags

jshap commented on 2019-09-25 20:12 (UTC) (edited on 2019-09-26 00:49 (UTC) by jshap)

it's not a yay issue, it happens with just makepkg as well if you don't delete the packages first. it's just a normal issue with how makepkg chooses to download things based on if it thinks it's changed or not.

for a more esoteric use case, look at how firefox-nightly's pkgbuild works. for them the url does not change, and yet every day the tarball will. so in the source array they move the file to a different location based on $(date ...). obviously not asking you to do that, just saying that it is not completely unheard of to have to rename things which are downloaded.

but again, I'm not saying to attach the date, I'm saying just use the pkgrel.

tholinka commented on 2019-09-25 05:19 (UTC)

Deleting the patches (or just clean building) does fix the checksum issue.

However, an even better solution (imo), since you already have to update this package with the new checksums, is to just copy the patches into this package instead of having them source from github. This comes with the added benefit that it's easy to see a diff between the versions.

« First ‹ Previous 1 .. 32 33 34 35 36 37 38 39 40 41 42 .. 82 Next › Last »