On 03/24/2016 09:54 AM, George N. White III wrote:
On Wed, Mar 23, 2016 at 9:06 PM, Rick Stevens <ricks@xxxxxxxxxxxxxx
<mailto:ricks@xxxxxxxxxxxxxx>> wrote:
On 03/23/2016 04:31 PM, George N. White III wrote:
On Wed, Mar 23, 2016 at 7:57 PM, François Patte
<francois.patte@xxxxxxxxxxxxxxxxxxxx
<mailto:francois.patte@xxxxxxxxxxxxxxxxxxxx>
<mailto:francois.patte@xxxxxxxxxxxxxxxxxxxx
<mailto:francois.patte@xxxxxxxxxxxxxxxxxxxx>>> wrote:
Bonsoir,
I am wondering what is in mind of packagers.... I have just
fought for a
couple of days to have the printing service working on a
fresh fc23
install.
1- cups-browser.service is not enabled by default.
cups.service is
enabled but you cannot add printers. ok! With a little
work, you can
find why you cannot add printer.
2- Once this service is enabled, you can add your printer:
your network
printer is found without any problem, you can find the
right driver in
the default printer list.... So far so good! Then you test
your install
sending a test page and.... "filter failed"! What does that
mean?
3- googleling gives you tons of results and none of them give a
solution: filter failed, filter failed.... What is this
filter? driver?
Is my printer too old and none of the new drivers will
work? Must I buy
a new printer?.....
4- A light comes to you: "and if it was a firewall
problem?" Hurrah!
You have found the solution....
Will it be so difficult in the install process to enable
the browser
cups service at the same time the cups service is enabled
(and it is
enabled by default)? Is it so difficult to add an accept
rule for port
631 to iptables if cups service is enabled or, at least,
send a warning
when cups is enabled in order to remember to root to enable
port 631 in
iptables rules?
I had much the same experience this week with SL7 and apcupsd.
Fedora exists because there are many such issues that make the
difference between a robust distribution and a collection of
packages.
When (nearly) all issues like this are solved you have RHEL..
The two of us really should file bug reports against cups and
apcupsd
packages with the proposed firewall configuration details. I
would have
done this, but the system in question is off net which adds enough
extra hassle that I probably won't get around to filing a bug
report.
This is a security issue. Automatically opening your firewall to permit
ipp and such could be inviting attacks from the outside world.
Obviously, if your machine is behind another firewall protecting you
from the big, bad Internet then yeah, there's really no problem with
opening up ipp and such on your _machine's_ firewall.
In my case, the SL7 machine is not on the internet at all.
In practice, many users will just disable the firewall completely
when they suspect it is blocking access to something they need
like a network printer.
Which is a foolish thing to do, as you well know.
Ideally installers would offer to configure
the firewall and do it only if the users says OK, but then you
create problems for unattended installs.
Yep, but then again unattended installs (and updates) are dangerous
beasties by their very natures. We don't permit them in our networks.
A human must supervise installs and updates. Granted, they sometimes
miss things, but we've had far better luck doing this. The automatic
update to docker that introduced that incredibly stupid bug for etcd
that broke TONS of stuff (who the h*ll does their QA anyway?) is one of
the things that drove our policy.
Adding an appropriate "/usr/lib/firewalld/services/XXXX.xml"
file does 90% of the heavy lifting. Many users will only need to
run "|sudo firewall-cmd --add-service=XXXX". ||If
|
|we are trying to encourage users to keep firewalls
|
|running, then we should insist that all packages which
|
|require changes to the firewall provide the suggested
|
|configuration file(s).
As you point out, for unattended installs this still presents a
problem. And regardless of whether you provide a firewall config, it is
still up to the sysadmin to actually implement the changes (e.g. having
to run the "firewall-cmd --add-service" command), which is what I said.
Not to pick nits, but your solution presents another aspect of things
which should be looked at--it is only valid for people using firewalld.
I, for example, still prefer iptables so your solution wouldn't work
for me. In such cases, the package would have to take into account
holdouts and wackos such as I. :-)
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- He who laughs last thinks slowest. -
----------------------------------------------------------------------
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
