Closed PromoFaux closed 4 months ago
Question:
Why do we need to use the --upgrade
option?
I tested adding grep
to the list of packages to be installed and the result was the same.
pidev:/# grep -V
grep (GNU grep) 3.11
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Mike Haertel and others; see
<https://git.savannah.gnu.org/cgit/grep.git/tree/AUTHORS>.
grep -P uses PCRE2 10.42 2022-12-11
Maybe we do not... @yubiuser made the comment here that it did not work when he tried, and so I took the upgrade
option from a comment you made elsewhere and it worked.
I didn't try it without upgrade
before based on Yubi's comment, but having since tried it I can confirm it is now working
Something must have changed in between so that it is working now with only grep
being available.
I testet it with the container now and bosth -b/-w
work.
P.S. Adding grep
was the lazy way ;-) list.sh
still uses the direct database access. At some point we should re-write it to use FTL
and the new API :-)
Yeah, absolutley agree on that - just going for the quickfix option for the time being :)
We have code for CLI lists via API ready for quite some time but there was an ongoing discussion because this change then introduces authentication for these CLI options while there was none before. We discussed this shortly back in the days but never came to a conclusion what we wanted to do IIRC. Eventually, it was forgotten.
My latest suggestion was to change the default of webserver.api.localAPIauth
to false
(it currently default to true
) but this is also not the optimal solution effectively allowing the CLI to use the API at will without password.
CLI domain searching is also ported to the API and we added a separate option for it (webserver.api.searchAPIauth
) - if we'd decide for my suggestion, this special option could be removed again - which I'd absolutely love to do!
I don't remember what my position was when we discussed this back then, but today I think we should not let the cli to bypass the authentication by default. We have https://github.com/pi-hole/pi-hole/blob/development-v6/advanced/Scripts/api.sh which can handle cli authentication so there should be no need to allow bypassing it. (I admit it is a bit cumber-stone to re-authenticate for each added black/whitelist entry - unless we store the SID somewhere and don't delete the session)
Yes, storing the session somewhere in the respective user's home should solve this. Maybe we create a directory ~/.pihole
and store a file called api_sid
in there. We can always throw this against the API and it will either accept or reject it, the latter forcing the user to re-login.
Users will complain, but probably not too hard. We could offer the possibility to create a file ~/.pihole/api_pw
where users can enter either their Pi-hole's normal or application password to cause the CLI to auto-login.
Storing the password could work, BUT how would we do that in such a way that it doesn't lead to the possibility of the password being compromised?
I wouldn't store the password. I think it's fine to request re-login after the session has expired. Saving the SID should make it very convenient already.
That's what the application password has been designed for. If they use (and store!) it in some Python scripts in their home directory programmatically interacting with the API, why not allow them to store it in an equally "safe" (that's why I said in /home/<user>
) place?
So maybe we just preface it with "you can do x but it is at your own risk"
SID maybe the better option, mind.
We'll do SID anyway but it will still require relogin after some inactivity.
This is how the AWS CLI utility handles it. I think that's a pretty good model to use?
What does this PR aim to accomplish?:
Fixes https://github.com/pi-hole/docker-pi-hole/issues/1577 by replacing
busybox
'sgrep
- which does not include theP
optionBefore:
After:
By submitting this pull request, I confirm the following:
git rebase
)