Obscure bug? Confirm banner message during package install => "install failed"
-
Or the package should not be using system alerts to notify about a package issue happening in the background during the install.
That isn't exactly it's intended use.
The notifications are working as they always have.
-
Not quite sure I understand. What are these messages to be used for then?
I've only seen them used for things like:- ssh keys have been created and ssh is activated
- xyz was reloaded
- etc.
The Dansguardian message seems to be falling into that sort of category, unless the other uses of that alert feature are similar abuses.
Or are you suggesting the alerts are OK, but they should not be posted while things are being installed, i.e. the packages should test for installs in progress before putting such an alert up?
-
They're supposed to be major issues that need you immediate attention.
- SSH keys created (if you didn't do this, you have a problem)
- Filter rules failed to load (you could be unprotected because the firewall rules are not in effect)
- XMLRPC Sync failure (the secondary may not have current firewall rules)
- Automatic Backup failed to save (could leave you without a working backup)
Some others include:
- Configuration file is corrupt
- CARP VIP tried to activate on an interface that mismatched its subnet
- Firmware upgrade failures
…and so on...
basically, the kind of things that, if you see them, you'd really want to stop what you're doing to address them. -
I'm converting these alerts to jquery to avoid this page reload, so if it's commited, will not be a problem clicking it at install process any more. :)
-
I'm converting these alerts to jquery to avoid this page reload, so if it's commited, will not be a problem clicking it at install process any more. :)
Sweet! Thanks!
-
That's great, but please don't consider that a reason to (ab|over)use the notifications :-)
-
That's great, but please don't consider that a reason to (ab|over)use the notifications :-)
sure :) The dansguardians alerts are for xml rpc sync errors and blacklist download finish.
Both needs admin attention.
-
blacklists downloading/failing, imo, isn't a good reason to notify. Squidguard never had to, it was all just handled on the squidGuard blacklist download page even when it was going in the background
-
blacklists downloading/failing, imo, isn't a good reason to notify. Squidguard never had to, it was all just handled on the squidGuard blacklist download page even when it was going in the background
I disagree a little. pfSense has so many pages, particularly with a bunch of packages installed, that if I had to visit all the various configuration pages to figure out if snort, dansguardian, HVAP, mailfilter, etc. had any issues updating rules, etc. it would be a full time job to keep the system maintained.
I should never have to go to any page, except for initial setup, when I explicitly want to change the configuration, or when I'm alerted that something is wrong. The only page I should have to look at, is the Dashboard. So unless there are status widgets for every module or some other shared mechanism by means of which packages can alert the admin, I'd think that's a good use of the alert mechanism.
So maybe that means we need to have a mechanism that more useful than digging through log files, and less urgent than these alerts…
-
The issue there is that the blacklist download is initiated in the background without the user telling it to happen - automated downloads of such things are typically frowned upon as the files are quite large and the ones that are free can incur quite a bandwidth cost if everyone kept downloading them over and over.
You should have to visit someplace to force-start the blacklist download and return there (or stay there) to see what happened. I sure wouldn't want such a thing to happen without my knowledge.
There's no hunting around for such things, if you know it's happening, you should be able to locate that in the package's settings. Granted I haven't used Dansguardian yet myself, but it's fairly obvious in squidguard that the blacklists are there under "blacklists"…
-
The issue there is that the blacklist download is initiated in the background without the user telling it to happen - automated downloads of such things are typically frowned upon as the files are quite large and the ones that are free can incur quite a bandwidth cost if everyone kept downloading them over and over.
You should have to visit someplace to force-start the blacklist download and return there (or stay there) to see what happened. I sure wouldn't want such a thing to happen without my knowledge.
There's no hunting around for such things, if you know it's happening, you should be able to locate that in the package's settings. Granted I haven't used Dansguardian yet myself, but it's fairly obvious in squidguard that the blacklists are there under "blacklists"…
Well, the admin decides in the Dansguardian settings how often the blacklists are updated, so it's not much different from having HAVP download periodically new anti-virus definitions, or system scripts regularly trimming log files, or any other automated scheduled maintenance. Dansguardian doesn't "randomly" do anything automatically, you have to set the interval, etc. The default setting is NEVER, and the blacklist URL is empty. So it requires admin action for anything to be downloaded, be it once, or periodically.
Of course, at this point, since I haven't even set up Dansguardian yet, it complains that the blacklist URL is not set, and that it can't download rules, because after an upgrade (package reinstall!) all rules are nuked.
-
Ah, then that's still something wrong in the package… It shouldn't be notifying for a configuration issue especially if it's valid. (if it's set to never and you have no blacklists, it shouldn't notify you that it can't download them...)
