incoming ssh/sftp blocked by iptables

[Jeff Spaleta]

On Thu, 15 Apr 2004 09:48:08 -0400, fulko.hew at sita.aero 
> ie. without a  lot of effort... how was _I_ supposed to know that
>     the firewall had turned _itself_ back on?

The firewall re-enable is of course a bug, and was not expected to happen.
Not sure if its really worth development time, to provide drop-dead easy
end-user sub-system interaction notification to workaround an obvious
selinux bug. The test system should not have reconfigured itself in
this way its a bug. I not really sure there is a good and obvious way
to notify the average person about bugs like this in the general
case...because well..there could always be a bug in the notification
attempt to notify about bugs.

That being said, the general issue of how to prevent unknowledgeable
people from hitting a problem they were not expecting, from a
subsystem they don't know about, when doing advanced things is going
to be very very hard to try to do in the way you have suggested. which
is to give instant feedback through gui-ish wizards like the services
start wizard when subsystems are interacting in expected ways. If
thats even possible its going to be tough.

Instead I would point you to the system logs /var/logs/ and a log parser.  
redhat-logviewer exists as a gui tool, and the logwatch parser exists
to create nightly emails to root user, its script based so it should
be more than flexible enough to grow a brain about iptables issues. So
the easiest and most comprehensive approach to notification is to make
log watching and log parsing easier to find and more in your face. 
And even if it were technically possible, the problem is how does the
system know that whatever conflict that is arising its actually a
conflict and not a delibrate configuration...very difficult for the
system to know what the local sysadmin wants is different than local
actions that are being taken.

But if the goal is to just get local sysadmins more notification about
local activity tying in logparsing into the gui tools would make sense
to me.
Some ideas that pop into my head at the moment:

*Possibly, have the services wizard suggest users review the system
logs when making service changes.

*Possibly, the services wizard with a little help from some extra
logic in the initscript functions could grow a brain about service
start/stop changes. To notify users when things have turned on or off
last. Maybe have a datestamp of last change, maybe have some simple
color code hi-lighting to give an indication that the service was
start/stopped last time not through the gui wizard.

*Provide easier access to the logwatch reports that get generated to
the root user. Designation in firstboot of non-root user sysadmin
email addresses to get log reports might be a good to help get people
who don't know about the logging a heads up about it.

*Or tie the logwatch email summary reports into the redhat-logviewer tool
and make the logviewer gui the expected tool to be used by people like yourself.


These ideas of course will not help all scenarios, there are a
multitude of ways to actually start services and deamons up that might
not log information as well as running the initscript designed to
start the service.
But assuming, we are just talking about 'normal' service operations
that use the initscripts designed for the service, there should be a
way to tie in initscript functionality to a logparser like
redhat-logviewer and to the services wizard to give some extra
notification about services activity.
I just don't know whom to poke in the eye directly to talk about this,
and frankly i don't have a very good understand of the
state-of-the-art with the gui service related tools...im a commandline
whore. But if i get time I'll poke around about my ideas some more,
and maybe file an RFE in bugzilla.

-jef