headers
jeff b | 2 Oct 2000 14:01
Picon

Re: Re: 1.4.99-...0927

Steve Freitas wrote:
> 
> Geez, looks like SourceForge is going through convulsions.
> 
> I went to the mailing list archives and found what I wanted, though it
> hadn't showed up in my inbox yet:
> 
> >Create a sym link in /etc/atalk/uams/ from uams_dhx_pam.so to be
> >uams_dhx.so.
> 
> That solved the problem. Again, I was using the RPM and I needed to do
> that, so the RPM needs a tweak. I would suggest that this configuration
> (dhx through pam) be the default configuration. That way it's 'secure by
> default,' and if someone has older clients which need handling (e.g.
> cleartext or randnum), they can do it manually.

RPM needs the symbolic links? I'll fix the spec file that I'm using for
the pre2 release. Any other major packaging / whatever problems besides
the symlinks and my forgetting to run autogen.sh before I tarred it up
for distribution?

jeff
Permalink | Reply | 0 comments |
headers
Jonathan Newman | 2 Oct 2000 18:51

Sparc Solaris and 1.4.99

From this mail on the admin list, it seems as though the current

./configure; make; make install

doesn't work on Solaris.  Is anyone actively developing on Solaris, or
have a box they can test this on?  I don't have one at my disposal.

Jon

> -----Original Message-----
> From: Wulf-Dirk.Leuschner <at> epidauros.com
> [mailto:Wulf-Dirk.Leuschner <at> epidauros.com]
> Sent: Monday, October 02, 2000 8:38 AM
> To: netatalk-admins <at> umich.edu
> Subject: Instructions for Compiling 1.4.99
>
>
>
>
> This morning I downloaded 'm4', 'autoconf', 'automake', and
> 'libtool' from the
> GNU site, installed them, and tried to compile the sources
> with the newly
> generated configure file... and I got the following error messages:
>
> make  all-recursive
> Making all in libatalk
> Making all in adouble
> mksh: Fatal error in reader: = missing from replacement
> macro reference
(Continue reading)

Permalink | Reply | 501 comments |
headers
jeff b | 2 Oct 2000 18:12
Picon

atalkconf package

The atalkconf GUI frontend for the netatalk configuration files is
committed to CVS in the netatalk repository, under the "atalkconf" tree.

If anyone has any experience with GTK+, could they try to work on
bringing it up to speed with the changes in netatalk?

Thanks,
jeff
Permalink | Reply | 0 comments |
headers
Tim Carlson | 2 Oct 2000 19:42

Re: Sparc Solaris and 1.4.99

On Mon, 2 Oct 2000, Jonathan Newman wrote:

> >From this mail on the admin list, it seems as though the current
> 
> ./configure; make; make install
> 
> doesn't work on Solaris.  Is anyone actively developing on Solaris, or
> have a box they can test this on?  I don't have one at my disposal.

I'm getting around to this.. If a developer would like an account on one
of my Sun boxes (this is how Adrian fixed a few Solaris bugs), just let me
know.

Tim

Tim Carlson                                  Voice:    (505) 984-8800x255
Director of Computing: Santa Fe Institute    Fax:      (505) 982-0565
WWW: http://www.santafe.edu/~tim             Email:   tim <at> santafe.edu
Permalink | Reply | 501 comments |
headers
a sun | 2 Oct 2000 20:37
Favicon

Re: Umask support in netatalk 1.5* afpd?

   afpd doesn't (from my reading of the afpd code tree) take ANY sort of
   permission info from the client side. At all. Ever. It's just snagging the
   mode of the containing directory, and using that as the create mask for
   any files or directories created. Whether it follows the spec or not is,
   in my estimation, beside the point. The fact remains, for most purposes it
   is a broken and just plain bad assumption. Just because a user's home
   directory shouldn't be browsable or modifiable to the entire world (same
   with their public_html directory) doesn't mean we want any files created
   there to not be readable to anybody. (To take the situation I'm looking at
   as an example.)

umm, not all the world is unix. i would really suggest that you read
the spec and look more carefully at the code before calling something
a 'bad assumption.' AFP provides permission semantics that are
different from unix. that doesn't mean that they're wrong. they are,
in fact, simpler than unix semantics and reflect how HFS was
originally devised. many appleshare folks have lived quite well with
this behaviour, and i would be wary of introducing something that
changes it. afpd already screws up enough as it is with
permissions. i'd rather not make the matter worse.

fyi, files don't have permissions in the AFP world. directories do. if
you wish to change permissions, you do a 'get info' -> 'sharing' on
the directory and change it there. afpd tries to translate this to the
equivalent unix permissions, but it doesn't always do a stellar
job. when you add umasks, you've just increased the confusion for all
of the appleshare folks out there that expect permissions to be
determined by directory permissions. future revs in the appleshare
spec might allow a more closer alignment with how unix file
permissions work, but there's currently no way of translating that to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Freitas | 3 Oct 2000 07:57

Re: Re: 1.4.99-...0927

>Any other major packaging / whatever problems besides
>the symlinks and my forgetting to run autogen.sh before I tarred it up
>for distribution?

Hmm. Again, 1.4.99-...0927mdk RPM install on two virgin Redhat 7 systems. 
Connecting from an AppleShare 3.8.6 client (Sys 8.6) and from an OS 9 
client.

1. They always reports free space of 1.9 gigs, regardless of whether 
there are actually 150 megs free or 3 gigs free.

2. -savepassword and -setpassword options don't seem to work for me.

My afpd.conf looks like this:

- -transall -uamlist uams_dhx.so -savepassword -setpassword

I apologize if any of these are my fault -- but if I think it might be a 
bug, I'll report it. :-)

Steve
Permalink | Reply | 501 comments |
headers
Jonathan Newman | 3 Oct 2000 08:42

Re: Re: 1.4.99-...0927


On Mon, 2 Oct 2000, Steve Freitas wrote:
> 1. They always reports free space of 1.9 gigs, regardless of whether 
> there are actually 150 megs free or 3 gigs free.

I have seen this behavior too.  I think this is because of the > 2 GB
"fixes" that were introduced after the integration into CVS.

> I apologize if any of these are my fault -- but if I think it might be a 
> bug, I'll report it. :-)

That is certainly the best way of getting the issues resolved. :)

Jon
Permalink | Reply | 501 comments |
headers
Lance Levsen | 4 Oct 2000 10:26

libatalk/dsi/dsi_tcp.c

I'm getting a problem compiling from source and would appreciate some help.

Debian GNU/Linux
libc6-dev version 2.1.94-3
netatalk-1.4.99-0.20000927.tar.gz

From what i can read of it, there seems to be a problem with the structure in 
/usr/include/netinet/tcp.h but there doesn't seem to be a problem in that 
structure, that I can see anyway . . . my C is just above useless.

Here's a dump of the errors:

gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -I../../include -I../../sys 
-I/usr/local/ssl/include -I/usr/local/ssl/include/openssl 
-Wp,-MD,.deps/dsi_tcp.pp -c dsi_tcp.c  -fPIC -DPIC -o .libs/dsi_tcp.lo
In file included from dsi_tcp.c:27:
/usr/include/netinet/tcp.h:186: parse error before `uint8_t'
/usr/include/netinet/tcp.h:186: warning: no semicolon at end of struct or union
/usr/include/netinet/tcp.h:187: warning: data definition has no type or 
storage class
/usr/include/netinet/tcp.h:188: parse error before `tcpi_retransmits'
/usr/include/netinet/tcp.h:188: warning: data definition has no type or 
storage class
/usr/include/netinet/tcp.h:189: parse error before `tcpi_probes'
/usr/include/netinet/tcp.h:189: warning: data definition has no type or 
storage class
/usr/include/netinet/tcp.h:190: parse error before `tcpi_backoff'
/usr/include/netinet/tcp.h:190: warning: data definition has no type or 
storage class
/usr/include/netinet/tcp.h:191: parse error before `tcpi_options'
(Continue reading)

Permalink | Reply | 5 comments |
headers
jeff b | 4 Oct 2000 14:49
Picon

Re: AFPPasswd Utility (Was: 1.99gb window limit)

Basil Hussain wrote:
> 
> Hi,
> 
> > No, but it can still easily be decoded, each two characters is an
> > ASCII code in hexadecimal.  Now that you've posted your users'
> > passwords to a public mailing list, you might want to have them change
> > them..and you might want to discuss basic password security as well,
> > for example not using dictionary words :)
> 
> Hmm, so it is still basically 'plain text', but just in another form.
> Don't worry about those passwords, they were changed afterwards.
> Besides, what good's a password without a username and knowing which
> host they're from?
> 
> Anyway, you've made me remember something else to-do with afppasswd.
> Now, I know it's A Good Thing to use long, alpha-numeric passwords, but
> the trouble is, users just can't remember them! One thing I found using
> the afppasswd utility is that by default it doesn't allow you to set
> dictionary-based passwords (it uses cracklib to check, IIRC) unless you
> use the '-n' flag. This is sensible, but I think the default should be 
> more like the passwd utility, where it warns you sternly about setting a
> bad password, but still lets you do it.

I think I'm the guilty party responsible for the -n flag. I will modify
the behavior if there are no objections, but this comes down to a basic
sysadmin PEBKAC problem (Problem Exists Between Keyboard And Chair) that
users want the power of using networked computers, but don't want the
added responsibility of security. Kind of like driving a car, but
refusing to use your headlights at night because they are an extra
(Continue reading)

Permalink | Reply | 0 comments |
headers
jeff b | 4 Oct 2000 16:24
Picon

Re: Compiling netatalk-1.4.99 - ARRGGHH!!!

Wulf-Dirk.Leuschner <at> epidauros.com wrote:
> 
> My nth try to compile netatalk-1.4.99... (Solaris 32-bit mode)
> 
> What I did this time:
> 
> (1) Installed m4, autoconf, automake, libtool, and GNUmake
> (2) Merged libtool.m4 and aclocal.m4
> (3) Ran ./autogen.sh
> (4) Ran ./configure --prefix=/usr/local/atalk/
> (5) Started make (GNUmake!) and got:

-- SNIP --

> ../../include/atalk/adouble.h:35: sys/cdefs.h: No such file or directory
> ad_open.c:89: warning: `ADEDOFF_FILEI' redefined
> ../../include/atalk/adouble.h:136: warning: this is the location of the previous
>  definition

-- SNIP --

> Seems that the PATH to  cdefs.h is unknown. But how come that people
> compiling the same distribution on LINUX-systems do not have this
> problem???

Seems as though netatalk provides a wrapper for non-sys/cdefs.h systems
in sys/generic/sys/cdefs.h . I just modified the configure script to use
that if sys/cdefs.h isn't found.

The ADEDOFF_FILEI thing was a hack to keep code that worked with
(Continue reading)

Permalink | Reply | 0 comments |

Gmane