Subject: Re: [netatalk-admins] Netatalk vs CAP and Netatalk vs linux kernel 2.2
From: Geoff Thompson (geofft@waikato.ac.nz)
Date: Thu May 13 1999 - 17:47:30 EDT
Andy Jones wrote:
> Anyway, CAP 6 pl198 includes support for linux. However it seems this is
> linux circa the 1.2 kernel days. After various stops and starts, and
> after some bugs and debugging, I got it working on my 2.0.x RedHat box.
> A while ago I went to upgrade the kernel to 2.2.1, and CAP spat the dummy.
> In the kernel I found the following piece of code, in the file
> net/appletalk/ddp.c
>
> > /* netatalk doesn't implement this check */
> > if(usat->sat_addr.s_node == ATADDR_BCAST && !sk->broadcast)
> > {
> > printk(KERN_INFO "SO_BROADCAST: Fix your netatalk
> as it will break before 2.2\n");
>
> Could anyone (asun ?) offer some advice as to what this means, and what
> Netatalk had to do to work around this issue. Ideally I'd like to get CAP
> running on a 2.2 kernel and then made my mods available as patch 199 for
> anyone else who wants them.
Ick. Just as well you said this, (and I was watching), because we have
recently had CAP pl198, on a Linux kernel 2.0.34 run out of
filehandles/DDP sockets. I was going to upgrade the kernel to a 2.2
kernel, to try and raise the filhandles per process limit from 255 to
1023. From your experience, it doesn't look like a good thing to do.
I'm not sure if my problem is running out of DDP sockets, or
filehandles, but I definitely ran out of something before reaching the
User limit I set of 80. CAP didn't die, it just refused further
connections.
We have been using CAP to get authenticated printing, to be able to
charge for print jobs. CAP has been about the only way to reliably get
the print job off a Mac with a username attached to it. I'm not keen on
a Mac side solution, as I'm not confident with Mac security, and doubt
the Consultants in charge of each Mac lab, would be willing to have
something else pushed upon them. CAP avoids both issues.
However, the recent post to this list, mentioning that Netatalk can be
patched to do similar things is very encouraging. I don't know if it
will improve the Maximum number of users I can support (around 50), but
it at least would allow me to move to a product that is being more
actively maintained. It would also allow me to run Appletalk services
on a 2.2 kernel.
Has anyone else out there been able to support more than 50 users. I
would be interested to learn about their setup, and if any patches need
applying.
>
> On a secondary issue, would anyone like to comment about my apprehensions
> toward Netatalk? The version number made it seem like hacks upon hacks,
> so perhaps it would be less scary if just renamed to Netatalk v 1.5.
> Then again CAP 6 patch level 198 is hardly comforting, though there's
> only been one patch in about 4 years.
>
I don't know if the lack of patches for CAP in the last few years is a
sign of stability, or lack of interest. I am interest in moving to
Netatalk, mainly due to the amount of discussion it receives, and
development that it is getting. Andrew Sun has put a lot of effort into
netatalk, to provide for the newer Mac technologies, that CAP doesn't
cater for.
> Is it a case of constant upgrading, ala the Linux kernel in days gone by?
> How stable and reliable have people found Netatalk to be? Have people
> found strange or quirky bugs? Can anyone who has migrated from CAP to
> Netatalk offer any testimony about things which are improved or missing?
I think we should always upgrade Linux kernels where possible, not
necessarily for stability , but more for security. The few servers that
I look after (running kernel 2.0.34) have had uptimes in the hundreds of
days, so I don't find stability an issue anymore.
>
> Note that I'm not trying to pick a fight or denigrate the efforts
> which have gone into making Netatalk. I fully expect that at some time we
> will migrate from CAP to Netatalk. But right now, I'm wondering how it
> stacks up against CAP in a typical "business" situation, where Netatalk's
> supposed greater speed and efficiency don't matter. What matters is
> stability and reliability under moderate (and occasionally) heavy loads,
> and a fairly complete implementation of the AFP, ZIP and so on protocols.
I can't comment on the completeness of the Appletalk implementations.
However I would like to raise the possibility that a fast acting server
can deal better with a higher load, than a slow server. Machines tend
to be healthier with a lower load, peaking now and again, than a
constant high load. Netatalk may help provide a lower load per user
situation, than what CAP does.
When we had CAP installed on a DEC Unix server, using a packet filter to
get Appletalk onto the network, there were problems with dropped
packets, and corrupt print jobs coming through. CAP on a Linux server,
using the kernel DDP support has vastly improved reliability of
communications. Netatalk may be the next step up from that again.
Geoff.
----------------------------------
Geoff Thompson <geofft@waikato.ac.nz>
University of Waikato,
Hamilton, New Zealand
Ph: (07) 838 4748
Random Quote of the Minute :
And now for something completely the same.
----------------------------------
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:42 EST