p9100 not working

I think I might know what's rankling you here, since I
think that I just 
finally figured it out myself.

It would seem that any IP addresses that want to access the
P9100 
service need to be granted permission via:
    /etc/hosts.allow
?!?!?!?!

Anyway, togging my IP address in that file enables/disables
p9100 
printing for me.

To the package maintainer:
    - is it possible to remove the dependency on
/etc/hosts.allow since 
it would seem to be redundant with shorewall rules?
    - Alternatively, might the doc'n/helpfile 
(/var/lib/lrpkg/p9100.help) be updated to indicate this, um,
feature?   
    - Alternatively, maybe have a menu option to edit
/etc/hosts.allow 
by way of the lrpkg front-end for p9100d?

(I strongly propose the first since, I wager, few people
check the 
helpfile [due to not realizing that it's there, like I did
a while back 
for a different package] and the /etc/hosts.allow serves
other purposes 
- telnet permission comes to mind).

(FWIW I'm using
    "p910nd Version 0.6"
and it's always been good to me.)

Thanks to one and all for their work on LEAF!

scott; canada

C.Dummy wrote:
> Hello. I installed p9100 package lp parport and
parport_pc modules. 
> They load at boot no problem. I have put line in rules
in shorewall
>
> ACCEPT    loc    fw    tcp    9100:9102
>
> i edited root.dev.mk and root.dev.mod files and backed
up root. I can 
> print from 192.168.1.254 using
> command echo "test print" >/dev/lp0. So
Bering box is working. I can't 
> print from windows machines. I installed printer on
tcp/ip port 
> 192.168.1.254 on port 9100 RAW. Can't print. I'm
using bering uClibc 
> 2.3.1. Year ago I configured v 2.1.1 no problems. What
am I missing? 
> Is there any rule that supersede: ACCEPT    loc    fw  
 tcp    
> 9100:9102. I thought maybe SP2 and firewall but I just
switch from 
> cable to DSL and at the same time from 2.1.1
> to 2.3.1. 2.1.1 was working under sp2 in winxp.
> Thanks for halp
> Andrey


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
------------------------------------------------------------
------------
leaf-user mailing list: leaf-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Hello Scott,

> I think I might know what's rankling you here, since I
think that I just
> finally figured it out myself.
>
> It would seem that any IP addresses that want to access
the P9100
> service need to be granted permission via:
/etc/hosts.allow
> ?!?!?!?!
>
Correct, p9100nd is compiled with libwrap support.

>
> Anyway, togging my IP address in that file
enables/disables p9100
> printing for me.
>
> To the package maintainer:
> - is it possible to remove the dependency on
/etc/hosts.allow since
> it would seem to be redundant with shorewall rules?

It is possible to remove the dependency, but there is a
reason why p9100
(and a few other packages) are compiled with libwrap
support. LEAF is
modular, so it is possible to use LEAF without shorewall as
a pure router
or printserver (or whatever), libwrap gives some extra
security in the
cases where iptables/shorewall isn't installed.

> - Alternatively, might
> the doc'n/helpfile (/var/lib/lrpkg/p9100.help) be
updated to indicate
> this, um, feature?   

That's a very good suggestion ;)

> - Alternatively, maybe have a menu option to edit
> /etc/hosts.allow
> by way of the lrpkg front-end for p9100d?
>
That's a tricky one, the p9100d package doesn't
"own" the /etc/hosts.allow
file. If we create an entry for that file in the p9100
package and an user
backups that package (and thinks he saved the hosts.allow
changes) the
changes are not saved. The hosts.allow file is owned by the
etc.lrp
package and that's why the config entry is presented in the
general
"network configuration" entry. Besides, there
are more packages which
depend on hosts.allow.

> (I strongly propose the first since, I wager, few
people check the
> helpfile [due to not realizing that it's there, like I
did a while back for
> a different package] and the /etc/hosts.allow serves
other purposes -
> telnet permission comes to mind).
>
> (FWIW I'm using
> "p910nd Version 0.6"
> and it's always been good to me.)
>
> Thanks to one and all for their work on LEAF!
>
>
> scott; canada
>
Eric



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
------------------------------------------------------------
------------
leaf-user mailing list: leaf-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Hello Sam,

> I have just installed bering uclibc 2.4, as a
replacement for
> 1.something(?3?).
> Nice work everyone! Especially shorewall, I haven't
looked there for a
> year or so.  The macro and action parts is v.nice
indeed. I did:
>
>
> - print out all the files,
> - think about what they could mean and
> - type in something that does similar in the new idiom
>
>
> ... so I hope that I haven't carried across any old
boo-boos.
>
>
> So far, DNSmasq has stopped twice. I have not debugged
it yet....
> I just patched it up to 2.27 rev 1, let's see if that
makes a difference.
>
There is a small bug in dnsmasq, the author is working on a
patch. I hope
it will be available soon.

>
> Dropbear appears to be missing this: ln -s
/usr/sbin/dropbear
> /usr/sbin/scp.
> Is that right?
>
Scp should be linked to dropbearmulti and on my system
that's the case. Do
you get a usage message when you type scp?

Eric



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
------------------------------------------------------------
------------
leaf-user mailing list: leaf-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

On Sun, 9 Apr 2006 10:31:18 +0200 (CEST), Eric Spakman wrote
> 
> > I think I might know what's rankling you here,
since I think that I just
> > finally figured it out myself.
> >
> > It would seem that any IP addresses that want to
access the P9100
> > service need to be granted permission via:
/etc/hosts.allow
> > ?!?!?!?!
> >
> Correct, p9100nd is compiled with libwrap support.
[snip]
> It is possible to remove the dependency, but there is a
reason why p9100
> (and a few other packages) are compiled with libwrap
support. LEAF is
> modular, so it is possible to use LEAF without
shorewall as a pure router
> or printserver (or whatever), libwrap gives some extra
security in 
> the cases where iptables/shorewall isn't installed.
> 

We use LEAF without shorewall for other things.

Could security for a libwrap-supported package be pointed at

another one of the common Linux host access allowance files
like 
"hosts.lpd" instead of
"hosts.allow"?  Then the p9100 package could 
"own" the file and provide editing in the
administrative interface 
without messing other things up.

---Hillel



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
------------------------------------------------------------
------------
leaf-user mailing list: leaf-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Hello Hillel,

>> It is possible to remove the dependency, but there
is a reason why
>> p9100 (and a few other packages) are compiled with
libwrap support. LEAF
>> is modular, so it is possible to use LEAF without
shorewall as a pure
>> router or printserver (or whatever), libwrap gives
some extra security
>> in the cases where iptables/shorewall isn't
installed.
>>
>
> We use LEAF without shorewall for other things.
>
>
> Could security for a libwrap-supported package be
pointed at
> another one of the common Linux host access allowance
files like
> "hosts.lpd" instead of
"hosts.allow"?  Then the p9100 package could
> "own" the file and provide editing in the
administrative interface
> without messing other things up.
>
It's not clear to me what you mean, there is just one
hosts.allow file
which is used by multiple packages and also inetd in the
root.lrp package.
The hosts.allow file is a config file from the libwrap
library, not from
the p9100 daemon. It's not possible to use a different
"allow" file for
the p9100 package alone.

Eric



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
------------------------------------------------------------
------------
leaf-user mailing list: leaf-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Eric Spakman wrote:
>> To the package maintainer:
>> - is it possible to remove the dependency on
/etc/hosts.allow since
>> it would seem to be redundant with shorewall rules?
>>     
> It is possible to remove the dependency, but there is a
reason why p9100
> (and a few other packages) are compiled with libwrap
support. LEAF is
> modular, so it is possible to use LEAF without
shorewall as a pure router
> or printserver (or whatever), libwrap gives some extra
security in the
> cases where iptables/shorewall isn't installed.
>   
What you say makes sense (including what followed, about
hosts.allow not 
being part of pppd.lrp) but I'll offer this
counter-position.

To have two places where one must permit an IP address
(shorewall & 
hosts.allow) is a little obtuse, IMO.

In terms of LEAF as a non-shorewall router, etc I'd propose
that since 
the default LEAF distro includes shorewall that might tip
the scales in 
favour of recognizing that shorewall rules are the better,
*single* 
place for IP restrictions to be placed. Also, newbies (the
people most 
likely to get tripped up by this double-permission
requirement) are less 
likely to be able to solve this, then someone who is
employing LEAF as a 
non-shorewall device, whose users are much more likely to be
able to 
self-solve, recompile with libwrap support, etc.

Maybe 2 pppd.lrp packages - one default for use with
shorewall (no 
dependency on hosts.allow) and one standalone? (recognizing
too that 
more packages = more work for the kind, volunteer
maintainers).

This conundrum all might all originate from trying to make
LEAF do more 
than one thing - firewall & router vs router vs print
server (doing two+ 
things - and the commensurate double-permissions
requirement, is maybe a 
not-unexpected outcome of trying to do more than one thing
and causing 
neither task to be performed optimally).

Is there any reason that someone who wants to use LEAF as a,
say, print 
server, *shouldn't* use shorewall to effect IP addy
restrictions? 
(Saving space on a floppy is obvious but is there anything
more 
substantial? And true, adding in a complex package like
shorewall vs 
compiled-in libwrap support exposes a greater risk of
code-bug that 
impacts security). Anything else?  

Anyway, I'm obviously not an impartial party here but
wanted to offer 
the devil's advocate position, in terms of identifying the
'cost' 
associated with the 'benefit' of this multiple-use
strategy.

Too, things that make life tough for newbies (I'm not one,
FWIW) are a 
Bad Thing, again IMO.

Regardless of the final decision I thank you for your taking
the time to 
reply and explain.

(I also like what Hillel Seltzer said, in terms of
"hosts.lpd instead of 
hosts.allow'" and IMO think that would be a
alternate, ideal solution 
since hosts.lpd could [TTBOMK] be safely made a part of the
pppd.lrp 
package?!)

scott; canada


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
------------------------------------------------------------
------------
leaf-user mailing list: leaf-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Hello Scott,

>> It is possible to remove the dependency, but there
is a reason why
>> p9100 (and a few other packages) are compiled with
libwrap support. LEAF
>> is modular, so it is possible to use LEAF without
shorewall as a pure
>> router or printserver (or whatever), libwrap gives
some extra security
>> in the cases where iptables/shorewall isn't
installed.
>>
> What you say makes sense (including what followed,
about hosts.allow not
> being part of pppd.lrp) but I'll offer this
counter-position.
>
That should be p9100.lrp I guess 

> To have two places where one must permit an IP address
(shorewall &
> hosts.allow) is a little obtuse, IMO.
>
That's true, but if you are changing network settings from
their defaults
there is a change other things have to be changed too. This
is not only
true for /etc/network/interfaces, shorewall and
hosts.allow/deny but also
/etc/hosts /etc/resolv.conf and other places. Most of the
basic settings
are grouped in the "Network Configuration menu"
(including allow and deny
settings).

> In terms of LEAF as a non-shorewall router, etc I'd
propose that since
> the default LEAF distro includes shorewall that might
tip the scales in
> favour of recognizing that shorewall rules are the
better, *single* place
> for IP restrictions to be placed. Also, newbies (the
people most likely to
> get tripped up by this double-permission requirement)
are less likely to
> be able to solve this, then someone who is employing
LEAF as a
> non-shorewall device, whose users are much more likely
to be able to
> self-solve, recompile with libwrap support, etc.
>
When using the Bering-uClibc image without changing the
settings of the
local network nothing has to be changed in hosts.allow/deny.
If an user
changes the local subnet he has to change a lot of things,
this is not
something I would advice newbies todo. Besides if he screws
up, at least
he has double protection.

> Maybe 2 pppd.lrp packages - one default for use with
shorewall (no
> dependency on hosts.allow) and one standalone?
(recognizing too that more
> packages = more work for the kind, volunteer
maintainers).
>
I don't think this will improve the situation...

> This conundrum all might all originate from trying to
make LEAF do more
> than one thing - firewall & router vs router vs
print server (doing two+
> things - and the commensurate double-permissions
requirement, is maybe a
> not-unexpected outcome of trying to do more than one
thing and causing
> neither task to be performed optimally).
>
LEAF is perfectly capable of doing multiple tasks, it's
just linux. It all
depends on which packages you load.

> Is there any reason that someone who wants to use LEAF
as a, say, print
> server, *shouldn't* use shorewall to effect IP addy
restrictions? (Saving
> space on a floppy is obvious but is there anything more
substantial? And
> true, adding in a complex package like shorewall vs
compiled-in libwrap
> support exposes a greater risk of code-bug that impacts
security).
> Anything else?  
>
Yes, there are reasons. I also use LEAF as a VOIP server
(using Yate) on
my DMZ, there is no need for shorewall on that box, it will
make things
even more complicated when adding that.

>
> Anyway, I'm obviously not an impartial party here but
wanted to offer
> the devil's advocate position, in terms of identifying
the 'cost'
> associated with the 'benefit' of this multiple-use
strategy.
>
Very much appreciated.

> Too, things that make life tough for newbies (I'm not
one, FWIW) are a
> Bad Thing, again IMO.
>
>
> Regardless of the final decision I thank you for your
taking the time to
> reply and explain.
>
It's an interesting discussion, I'm also not sure what the
best solution
is so any argument is appreciated.

> (I also like what Hillel Seltzer said, in terms of
"hosts.lpd instead of
> hosts.allow'" and IMO think that would be a
alternate, ideal solution since
> hosts.lpd could [TTBOMK] be safely made a part of the
pppd.lrp package?!)
>
That's not possible, hosts.allow (and deny) are config
files for the
libwrap library. It has nothing todo with the p9100.lrp
package itself and
you can't change the filename.

> scott; canada
>
Eric





-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
------------------------------------------------------------
------------
leaf-user mailing list: leaf-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Hi scott,

> In terms of LEAF as a non-shorewall router, etc I'd
propose that since
> the default LEAF distro includes shorewall that might
tip the scales in
> favour of recognizing that shorewall rules are the
better, *single*
> place for IP restrictions to be placed. Also, newbies
(the people most
> likely to get tripped up by this double-permission
requirement) are less
> likely to be able to solve this, then someone who is
employing LEAF as a
> non-shorewall device, whose users are much more likely
to be able to
> self-solve, recompile with libwrap support, etc.
I think we have different views of what a
"newbie" might be. To me,
somebody who turns a distro that's mainly a firewall (by
it's default
settings, surely not by any limits it might impose) into a
print-server,
should not be considered a newbie as far as I'm concerned.

> Maybe 2 pppd.lrp packages - one default for use with
shorewall (no
> dependency on hosts.allow) and one standalone?
(recognizing too that
> more packages = more work for the kind, volunteer
maintainers).
I don't quite get the issue here - if you don't want to
use libwrap
checking, simply add "ALL: ALL" to your
/etc/hosts.allow (unless I'm
missing something). No need to create tons of extra
packages, simply a
configuration change resulting from a decision the person
configuring
the box makes (a decision to give up an extra layer of
security, because
it is not needed in this specific case).

What you propose could result in a maintenance nightmare
(creating two
versions of every package that is currently compiled against
libwrap -
you're only proposing pppd.lrp - even though it sounds like
you're
actually referring to p9100.lrp - but I'm sure that if we
look hard
enough, we'll find somebody to propose the same thing for
every other
package that currently uses libwrap).

> This conundrum all might all originate from trying to
make LEAF do more
> than one thing - firewall & router vs router vs
print server (doing two+
> things - and the commensurate double-permissions
requirement, is maybe a
> not-unexpected outcome of trying to do more than one
thing and causing
> neither task to be performed optimally).
I'm not a fan of doing more than routing/firewalling on my
router/firewall, but to each his own, I guess (to me, adding
services to
a firewall adds potential security issues). I'm a big fan
of dedicated
boxes - but maybe I simply have the luxury of having extra
boxes
available, so I don't need to squeeze everything into one
box.

> Is there any reason that someone who wants to use LEAF
as a, say, print
> server, *shouldn't* use shorewall to effect IP addy
restrictions?
Not that I know of. But I don't see your point - are you
suggesting that
because one _can_ use shorewall on a print-server, one
should not use
extra security features the software offers, since if one
uses
shorewall, they would be useless (by the way, I don't
subscribe to that
idea, since I believe in multiple layers of defense)?
Don't get me wrong - I can surely understand where you're
coming from.
The way it sounds to me, you're frustrated because a
compile time
setting (that adds something you don't need) has made life
more
difficult for you than it should have been, and the lack of
documentation has made finding the problem difficult. I can
surely
relate to that - but I still don't see why one should throw
away the
sane (and possibly safer) default config.

> (Saving space on a floppy is obvious but is there
anything more
> substantial? And true, adding in a complex package like
shorewall vs
> compiled-in libwrap support exposes a greater risk of
code-bug that
> impacts security). Anything else?  
Having both at the same time is nice. And I wouldn't call
shorewall a
"risk of code-bug" - it's a well written, well
maintained, well
documented piece of software (no offense - I don't think
that's what you
wanted to say - I just didn't want to leave that line
without comment).
Having another layer of security is nice - any serious flaw
in IPTables
will render shorewall useless, and it's not like flaws in
IPTables have
never been found.

> Too, things that make life tough for newbies (I'm not
one, FWIW) are a
> Bad Thing, again IMO.
Absolutely. That's why I agree that documenting the
dependency on
libwrap is a good thing, and I'm glad to see that Eric has
already
updated the help file for the package.

> (I also like what Hillel Seltzer said, in terms of
"hosts.lpd instead of
> hosts.allow'" and IMO think that would be a
alternate, ideal solution
> since hosts.lpd could [TTBOMK] be safely made a part of
the pppd.lrp
> package?!)
As Eric said - that's not how libwrap works. It would be
nice to have an
/etc/libwrap.d/ directory, where each package could put its
own config
files (which would all be read by libwrap), but that's not
how things
work at the moment. Maybe the author would be willing to add
such a
feature, if he were asked.

As always, the views expressed in this mail are mine alone,
I'm not
speaking for anybody else. And I'm not out to hurt
anybody's feelings,
I'm simply trying to state my point of view as clearly as I
can.

Martin



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
------------------------------------------------------------
------------
leaf-user mailing list: leaf-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/