Bug #7454
closed
bridge is up after reboot while the enable interface box is not checked
0%
Description
as described, I add an bridge to bind two different interface, but I do not want the bridge be brought up, so I uncheck the enable box in the interface configuration tab, it works for the change. however when I reboot, the bridge interface is up again though the configuration shows that it's not enabled
Updated by giskard rt over 7 years ago
the similar problem also exist with some other add-ons, like:
1,squid, though it's not enabled, it generate a lot or warnings like "No HTTP, HTTPS, or FTP ports configured", while I didn't select any interface and unchecked all the enable box for squid service as the user uinstruction said;
2,snort, I have to delete the added snort interface thought it's stopped, or the snort will listen on these interface automatically after reboot;
Updated by Kill Bill over 7 years ago
giskard rt wrote:
I uncheck the enable box in the interface configuration tab, it works for the change. however when I reboot, the bridge interface is up again though the configuration shows that it's not enabled
Yeah, otherwise you'd get a super-broken box and prompt to re-assign interfaces on reboot. Unchecking the box is NOT the way to disable bridging for obvious reasons.
the similar problem also exist with some other add-ons, like:
This just doesn't belong here.
- As for Squid, the logging is required for debugging user misconfiguration and other problems and I definitely have no plans to remove it.
- As for Snort, this yet again is by design, stopping the instance does stop the instance, it does not disable it. Likewise, stopping any other service stops the service, it does not disable it. That's completely expected and standard behaviour, across operating systems. Stop is NOT the same thing as disable.
I think there's some fundamental misunderstanding about what's the purpose of https://redmine.pfsense.org/ - it is a bug tracker. I.e., file confirmed specific bugs (previously discussed and confirmed via the forums) or feature requests here, one per ticket filed.
Updated by Jim Pingle over 7 years ago
- Status changed from New to Rejected
Interfaces exist at the OS level even when they are not enabled. The GUI only controls settings applied to the interfaces. Bridges can work when they are assigned or not, so they are handled in a special way as well.
This is normal, please post on the forum to discuss and confirm problems before opening issues here on Redmine.
Updated by giskard rt over 7 years ago
Kill Bill wrote:
giskard rt wrote:
I uncheck the enable box in the interface configuration tab, it works for the change. however when I reboot, the bridge interface is up again though the configuration shows that it's not enabled
Yeah, otherwise you'd get a super-broken box and prompt to re-assign interfaces on reboot. Unchecking the box is NOT the way to disable bridging for obvious reasons.
As I think, if the bridge exist(assigned with interfaces), itself can have a state up or down which decide whether the bridge interface works or not, just like bridge in linux. So when I add a bridge and assign it with some interface, it comes into exist; after I check the enable box, the bridge interface should be bring up, or unchecked to set it down. So that if I do not need the bridge I can set it down rather than delete it, this is more convenient as I do not need to re-add bridge and assign related interfaces if I want it later.
As a matter of fact, maybe just misunderstanding, when I unchecked the enable box for the bridge in the interface tab, it indeed comes into a state like 'down', and I can set it up by just check the enable box. the bridge is still there.
the similar problem also exist with some other add-ons, like:
This just doesn't belong here.
- As for Squid, the logging is required for debugging user misconfiguration and other problems and I definitely have no plans to remove it.
if a user want to disable squid service for some time, then he or she maybe think the service is disabled so it's no sense to debug a stopped service during that time, and especially this debug just generate a lot of useless log file and use a lot disk space while the user only install the plug-in but not intend to enable it for now.
- As for Snort, this yet again is by design, stopping the instance does stop the instance, it does not disable it. Likewise, stopping any other service stops the service, it does not disable it. That's completely expected and standard behaviour, across operating systems. Stop is NOT the same thing as disable.
This comes from my experience with using systemd, as there is options to record a service's last state and you can choose to recover it on bootup or not. So this may be considered more as a feature which may be worthy of add.
I think there's some fundamental misunderstanding about what's the purpose of https://redmine.pfsense.org/ - it is a bug tracker. I.e., file confirmed specific bugs (previously discussed and confirmed via the forums) or feature requests here, one per ticket filed.
Yes，I'm not familiar with this yet, later for these problems, I will post on the forums before discussing here, sorry.
Updated by Kill Bill over 7 years ago
giskard rt wrote:
if a user want to disable squid service for some time, then he or she maybe think the service is disabled so it's no sense to debug a stopped service during that time, and especially this debug just generate a lot of useless log file and use a lot disk space while the user only install the plug-in but not intend to enable it for now.
No it doesn't. The logs are circular and fixed size.
Updated by giskard rt over 7 years ago
the system log is indeed limited to a fix size, however the suid service genarate cache log(path: /var/squid/logs/cache.log ) to 60M and seems not to stop, but the single log file only include message like "2017/04/08 11:01:44 kid1| ERROR: No forward-proxy ports configured." for the squid proxy service is not enabled.