Tools KUAL Firewall with BBB filter

[twobob]

It's tidier than having two archives.

perhaps that would be a "bomb-proof" solution though

[knc1]

Originally Posted by twobob

It's tidier than having two archives.

perhaps that would be a "bomb-proof" solution though

I did have thoughts about how to best do that.

An unusual situation, where the button has files associated with it that the user needs (or should have) but do not seem to deserve any space in the */extensions directory tree.

The rule-set is copyrighted material and licensed to the user.
So they really do need to have a copy of the license in this case.
The registration info on what is being filtered was requested by people on this forum in the past. Seemed a reasonable request.

So the best thing I could think of was two directories - move one, keep one.

Why the license?
Thought no one would ever ask -
Not only are firewall rule-sets an Intellectual Property of significant value - there are actually people who earn a (good) living writing them.

[twobob]

Yeah, it's a teaser.

for my part I thought the instructions were fine.
That said - the "End User" acceptance phase is always the real test of a methodology.

I thought you just included the license so people could see what a cool name you had

"making a (good) living" - hmm, I have heard of this.
We Morlocks try not to aspire too high

[slantybard]

I'm sorry, I didn't mean to stir up a discussion over the way the archive was made. I realized my mistake and thought to leave a comment on it for anyone else who might make the same silly mistake.

[knc1]

Originally Posted by slantybard

I'm sorry, I didn't mean to stir up a discussion over the way the archive was made. I realized my mistake and thought to leave a comment on it for anyone else who might make the same silly mistake.

If using a GUI interface to the unzip program, that is usually included as a "check box" option (to make a directory the same as the archive name) - just un-check it next time.

But since I claim to know nothing about "applications code" (including GUI interfaces), it really wasn't my area of expertise.

I just had to assume that the end-user knew the result of checking the check box(s) on whatever they are using.

[DuckieTigger]

Originally Posted by knc1

I just had to assume that the end-user knew the result of checking the check box(s) on whatever they are using.

What surprises me, that KUAL now goes into sub-directories if it doesn't find a menu.json? Another way to "fix" this problem is to not hardcode the firewall filter to /mnt/us/extensions/bbb/frags/fw-base.txt, but relative to the script. Change:

SRC='/mnt/us/extensions/bbb/frags/fw-base.txt'

to (for example):

SRC=$( cd $( dirname $0 )/../frags; pwd )'/fw-base.txt'

This way it does not have to be installed in /mnt/us/extensions/bbb if one wants to organize their extension folder maybe?

[knc1]

Nope.
Organization of the */extensions tree is the developer's task, not the end-user.

That does not prevent the end-user from changing the organization, just relieves the developer of having to support every conceivable change that end-users might apply to the organization.

If the end-user makes changes, the end-user has to support their own changes.

[DuckieTigger]

Originally Posted by knc1

Nope.
Organization of the */extensions tree is the developer's task, not the end-user.

That does not prevent the end-user from changing the organization, just relieves the developer of having to support every conceivable change that end-users might apply to the organization.

If the end-user makes changes, the end-user has to support their own changes.

Fair enough. Have to see how KUAL will change in future - priorities, sorting, grouping - it just going to have to do it without physically moving existing extensions around.

[twobob]

Originally Posted by DuckieTigger

What surprises me, that KUAL now goes into sub-directories if it doesn't find a menu.json?....?

Yep. it's in the aloop.sh changelogs "somewhere"


the other stuff is in the pipline

[stepk]

Originally Posted by DuckieTigger

Fair enough. Have to see how KUAL will change in future - priorities, sorting, grouping - it just going to have to do it without physically moving existing extensions around.

KUAL looks for valid extensions this way:

1. find all config.xml files under /mnt/us/extensions/ and ./extensions/
1.2. if the current config.xml file doesn't include a "name" property goto 1
1.3. if the "menu" property of this valid config.xml file isn't "json" then goto 1
1.4. if the "menu" property is an absolute path goto 1.5, if it's a relative path make it relative to the location of its config.xml folder
1.5. if the absolute/relative path of this menu.json file is valid process the json file else goto 1

Note: ./extensions in step 1 comes in handy for testing KUAL. Its actual location isn't accessible to end users unless they install usbnetwork.

[knc1]

Originally Posted by stepk

KUAL looks for valid extensions this way:

1. find all config.xml files under /mnt/us/extensions/ and ./extensions/
1.2. if the current config.xml file doesn't include a "name" property goto 1
1.3. if the "menu" property of this valid config.xml file isn't "json" then goto 1
1.4. if the "menu" property is an absolute path goto 1.5, if it's a relative path make it relative to the location of its config.xml folder
1.5. if the absolute/relative path of this menu.json file is valid process the json file else goto 1

Note: ./extensions in step 1 comes in handy for testing KUAL. Its actual location isn't accessible to end users unless they install usbnetwork.

But the current working directory when called from KUAL is /
I think you should disable that for the release versions -
If that means you have to make a few directories or something else (or conditionalize for testing) then do that.

This is *nix not Windows - "/" and "." are never in the search path for good reasons.

[NullNix]

Originally Posted by knc1

This is *nix not Windows - "/" and "." are never in the search path for good reasons.

. is never in the PATH because it would be a security hole, but this post is the first I've ever heard of anyone suggesting that / should be in the PATH it's not there simply because there's nothing in / itself that anyone would want to run. No security hole, just efficiency.

[twobob]

Originally Posted by NullNix

. is never in the PATH because it would be a security hole, but this post is the first I've ever heard of anyone suggesting that / should be in the PATH it's not there simply because there's nothing in / itself that anyone would want to run. No security hole, just efficiency.

What post? who is suggesting that? knc1 certainly isn't suggesting / should be, quite the opposite.

and - for the record... all my kindles do have a file that lives on / called WHAT...

[root@kindle root]# cat /WHAT

Kindle 3!

Not that I am saying for a second that is "good practice".

If you mean: "there's nothing in / itself that anyone would want to run BY DEFAULT" then I fully agree : )

perhaps a more sensible default path could be arranged... Any suggestions?

[stepk]

Originally Posted by knc1

But the current working directory when called from KUAL is /
I think you should disable that for the release versions -
If that means you have to make a few directories or something else (or conditionalize for testing) then do that.

This is *nix not Windows - "/" and "." are never in the search path for good reasons.

I will check.
BTW, I pushed the source earlier today, but I don't think twobob has built yet.

edit: you're right, it's / - I'm going to fix it and push again.

edit2: fixed, pushed.

[twobob]

Originally Posted by stepk

I will check.
BTW, I pushed the source earlier today, but I don't think twobob has built yet.

edit: you're right, it's / - I'm going to fix it and push again.

edit2: fixed, pushed.

You are right I hadn't noticed...

but I have now

but if you look in https://bitbucket.org/twobob/kual-system you will probably see where today went.

Including the EXTREMELY AWESOME new busybox in there.

If I NEVER have to do that config again? it will be WAY too soon.

Will delve into your commit. Thanks mate.