Replies: 1 comment 3 replies
|
Regarding rule creation: There are these red/green circles indicating whether a connection is allowed or denied. Click it to invert the action for the particular line. This creates or deletes a rule, whatever is necessary to allow or deny. If you see an arrow of the opposite color, click it to see details of the connection with opposite rule. Regarding config: I've gone for low complexity in implementation first. But you're right: It might be a better idea to merge configs. I'll add this to the list of possible improvements. |
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hello again.. Ok, just installed on a Debian 13 healess box and it's working! I have a few initial suggestions to make working with the web front end easier:
If I start running in default 'allow' mode, I'd like to be able to click on the traffic in the 'connection' area and make a rule for that connection. If that is now possible, I could not quickly figure out how to do it.
Ditto, if I'm in default 'deny' mode (which I haven't tried yet), I'd like to see a blocked connection and make a rule to allow it.
I'd like to be able to, in addition to edit or delete an existing rule, duplicate the rule and then immediately see the new duplicated rule, change it, and save it. All aspects of the rule should be duplicated including the 'notes' area.
For my first attempt to make the web ui available on the lan (not just localhost) I created empty file
/var/lib/littlesnitch/override/config/web_ui.tomland put only the entry I wanted to modify there, but then the service did not restart. So instead I copied/var/lib/littlesnitch/config/web_ui.tomlto/var/lib/littlesnitch/override/config/web_ui.toml, made my change there, and it did start. I think it's better practice to be able to only override certain config lines and keep the rest as the default (that you may update from time to time). I mean, you on-the-fly first take the shipped config file then the override file does the override only for directives that exist in it. I'm familiar with Apache working that way. But I'm not a programmer, so maybe you have your reasons.Anyway, thanks for releasing this software!
All reactions