Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Group management not being applied #187

Open
mattbxd opened this issue Nov 22, 2020 · 16 comments
Open

Group management not being applied #187

mattbxd opened this issue Nov 22, 2020 · 16 comments
Labels

Comments

@mattbxd
Copy link

mattbxd commented Nov 22, 2020

Completely clean install of Pihole v5.1.2, Interface 5.1.1, FTL 5.2

The whitelist script now adds itself into its own group. However, this group can not be applied to clients.

Example)

I now have two Groups. "Default" and "anudeepND/whitelist"

If I go to Group Management -> Clients

and I attempt to apply both Groups to a client, after clicking "Apply", Pihole will say "Successfully edited groups of client" but the selection box itself doesn't change. It stays on "Default".

Thus, the whitelist is now no longer being applied to any client.

If I go to Group Management -> Domains

and attempt to manually apply each whitelist domain, the same thing happens.

In conclusion, since the whitelist domains are in their own group but the group can not be applied to any client and therefore the whitelist is not working. Everything on the whitelist is currently being blocked if they are in one of the adlists. (ex s.youtube.com)

I believe it is based on the following pull request

#183

@Couto
Copy link

Couto commented Nov 24, 2020

Can confirm, I just ran the script, the domains were added, the anudeepND/whitelist group was created and assigned to each imported domain, but I can't apply it to any client (UI reports success, but the group is not actually applied), manually created groups still work fine.

@anudeepND
Copy link
Owner

I have reverted the PR that created group while installing. If anyone wants to remove the group, you can run this command in the terminal:

sqlite3 /etc/pihole/gravity.db "DELETE FROM 'group' WHERE id = 2552552551;"

@anudeepND anudeepND pinned this issue Nov 24, 2020
@mwoolweaver
Copy link
Contributor

Sorry about this. I wasn't aware of

The ID is automatically generated sequentially when you create the group

what @dschaper said is not stated in the documentation so my thinking was I could use a predetermined value for the groupID but it seems that's not the case so I will rework this so that it adds the group and then check for the ID afterwards.

@dschaper
Copy link

The database schema is the documentation.

@mwoolweaver
Copy link
Contributor

@dschaper
Copy link

Then it should have come up when you tested your changes.

@dschaper
Copy link

dan@raspberrypi:~ $ sudo sqlite3 /etc/pihole/gravity.db ".schema group"
CREATE TABLE IF NOT EXISTS "group"
(
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        enabled BOOLEAN NOT NULL DEFAULT 1,
        name TEXT UNIQUE NOT NULL,
        date_added INTEGER NOT NULL DEFAULT (cast(strftime('%s', 'now') as int)),
        date_modified INTEGER NOT NULL DEFAULT (cast(strftime('%s', 'now') as int)),
        description TEXT
);
CREATE TRIGGER tr_group_update AFTER UPDATE ON "group"
    BEGIN
      UPDATE "group" SET date_modified = (cast(strftime('%s', 'now') as int)) WHERE id = NEW.id;
    END;
CREATE TRIGGER tr_group_zero AFTER DELETE ON "group"
    BEGIN
      INSERT OR IGNORE INTO "group" (id,enabled,name) VALUES (0,1,'Default');
    END;

@mwoolweaver
Copy link
Contributor

again as i said previously that schema is not properly represented in the documentation

https://docs.pi-hole.net/database/gravity/groups/

@dschaper
Copy link

That's why you check the schema and test your changes before assume things. Do you really want to argue the point with me?

@mwoolweaver
Copy link
Contributor

you said

The database schema is the documentation.

and now you say

That's why you check the schema and test your changes before assume things.

not much to argue with... the docs aren't accurate... end of discussion...

@dschaper
Copy link

The database schema, that I just printed out for you, is the documentation. That's the definitive table of truth for any database. Something you check before you pump data blindly in to one. You also picked an integer that is over the maxint for a signed integer on a 32 bit platform.

We can only document so much and trust that people will look before they do things like blindly pump data in to a database and then not actually check their changes to see if it breaks the entire operation of the application. In this case perhaps we assumed too much.

@mwoolweaver
Copy link
Contributor

In this case perhaps we assumed too much.

so did I...

@SodaWithoutSparkles
Copy link

SodaWithoutSparkles commented Jan 8, 2021

So how could I solve that? I want to revert the changes so that I could use the group management normally
Referenced by this Reddit post

@mwoolweaver
Copy link
Contributor

can you run

sqlite3 /etc/pihole/gravity.db "SELECT * FROM 'group';"

and post the output?

@SodaWithoutSparkles
Copy link

0|1|Default|1606123676|1606123676|
3|1|Smart Home|1595830800|1606123676|
4|1|bypass|1595831059|1606123676|
6|1|Bypass Google Ad service|1606141006|1607000807|

Ran the command from readme.md to remove the group. Done already. The new groups that added after using whitelist.py was removed using the same command from readme.md but replaced the ID with the new group ID shown on the web GUI. Still unable to apply group changes.

@SodaWithoutSparkles
Copy link

Okay, I solved that. First I did a backup from the teleporter page. I then did a reconfigure(pihole -r), selecting the same settings as before. It should not change any of your settings. You may restore the backup, but I didn't need to. That solves it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants