headers
Simon Bazley | 1 Oct 2002 04:48

Re: [dr <at> jones.dk: Bug#162883: netatalk: According to NEWS, switching to CNID DB (with no warning) ?is BAD!]

Joe's gone away now, so you'll need to wait a week (or was it 3) for him to come back from his holidays.

I believe the situation is if for whatever reason, using whatever DID system, DID's get confused, it is
possible, however unlikely that files get deleted that shouldnt be.  However when CNID is working it is the
safest system.  "database corruption" comes
under the section DID's confused and is generally bad and warrants shutting down the server, deleteting
all databases and starting again, if you want to be 100% safe.

My system ran with did=last for 6 months with DID's confused on a daily basis and I don't recall anything
worse than lots of log warnings.  The problem comes about when a client deletes a file (puts it in the trash)
with one DID, that DID then gets
reassigned out of confusion, then the trash gets emptied.  For whatever reason I never had trash working on
network shares so when a client deleted a file, it went.  Hence no deletion problems.  I'd reccomend locking
out the network trash folders read only
if you're too conscerned.

Remeber inode and DID are not the same thing.  inode confusion would be very very bad.  DID confusion can
always be sorted by 'reseting' netatalk and all its DID databases (inode confusion would probably mean
reformatting your hard disk).

--with-did=cnid is the safest option.  It wouldn't be default if there was a better method.

Simon
Permalink | Reply | 0 comments |
headers
Joe Marcus Clarke | 1 Oct 2002 08:28
Favicon

Re: [dr <at> jones.dk: Bug#162883: netatalk: According to NEWS, switching to CNID DB (with no warning) ?is BAD!]

On Mon, 30 Sep 2002, Sebastian Rittau wrote:

> Could anyone with more insight into the current CNID situation comment,
> please?

This is no longer an issue.  The CNID layout has been the same since
1.5.3.  The cnid_maint script can be used to keep the consistency of the
database.

Joe

>
>  - Sebastian
>
> ----- Forwarded message from Jonas Smedegaard <dr <at> jones.dk> -----
>
> Subject: Bug#162883: netatalk: According to NEWS, switching to CNID DB (with no warning) 	is BAD!
> Reply-To: dr <at> jones.dk, 162883 <at> bugs.debian.org
> From: "Jonas Smedegaard" <dr <at> jones.dk>
> To: "Debian Bug Tracking System" <submit <at> bugs.debian.org>
>
> Package: netatalk
> Version: 1.5.5-1
> Severity: critical
> Tags: sid patch
> Justification: causes serious data loss
>
> The latest note on CNID DB in NEWS is this (below "Changes from 1.5.1"):
>
> * UPD: CNID DB code sync'd with the current CVS version.  NOTE: Using this
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Rogers | 1 Oct 2002 17:25
Picon

Re: Re: Netatalk-devel digest, Vol 1 #832 - 12 msgs

   From: Andrew Morgan <morgan <at> orst.edu>
   Date: Sun, 29 Sep 2002 15:09:48 -0700 (PDT)

   > But doing so is generally a good idea.  Why do you think it's not
   > recommended to run apache as nobody?  Any standard system user makes a
   > terrible sandbox user for applications.  That's why more and more
   > applications (such as apache and named) are using sandbox users.  I
   > strongly support a netatalk sandbox.

   Ummm, but Apache permanently drops privileges (on the child processes) to
   user nobody (or whatever was configured).

In theory, user "nobody" should be OK, because "nobody" is not supposed
to own any files, so cracking it shouldn't buy you anything.  But this
is widely disregarded in practice, so an app-specific user is better.

   But the point is to lose root privileges permanently, and as soon as
possible, so that a rogue client doesn't gain anything by exploiting
bugs in the server.  For afpd, this would be immediately after
authenticating and becoming the client user.  And afpd is pretty large,
and getting larger when you include the DB3 code, so it is becoming more
and more desirable to restrict the amount of code that has to run as
root.

   Apache has it easy, though; it can drop privileges as soon as it
starts listening to port 80, and never needs to become anybody else, or
even talk to a client as root.  (Personally, I run AOLserver, which
absolutely refuses to run as root.)

   Afpd kind of does this already when it switches to the connected user
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Bazley | 1 Oct 2002 19:09

Re: [Netatalk-admins] README.cnid

I've written a simplistic explanation of IDs.  Hopefully this will answer some question Admins might have. 
Its in doc/README.ids.

I've written it off the top of my head, so it may have typos, errors or inaccuracies.  If you spot any give me a
shout and I'll fix them.

I guess Joe still needs to write a more detailed explanation of cnid for the more hardened admin though.

Simon
Permalink | Reply | 0 comments |
headers
Robert Simonds | 1 Oct 2002 23:31
Picon
Favicon

Postscript Title

I am now using 1.5.5 and CUPS on my Red Hat 7.3
system. I must say it is the best Netatalk yet, great.

A request for help. When printing via Netatalk from a
Mac to the server with a printer set up using CUPS the
Title of the document is being lost. Does anyone have
a script that could get this from the file before it
is printed?

Many thanks,

Robert.

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Permalink | Reply | 0 comments |
headers
Joe Marcus Clarke | 2 Oct 2002 01:16
Favicon

Re: Netatalk-devel digest, Vol 1 #832 - 12 msgs

On Fri, 2002-09-27 at 15:57, Dan Wilga wrote:
> >  > >Another option would be to do all .AppleDB updates as root instead of the
> >>  >user.  Netatalk is capable of switching user back and forth between root
> >>  >and the logged in user.  When used correctly there is very little security
> >>  >risk.
> >>
> >>  Actually, I like that idea a lot, because it would also mean that the
> >>  .AppleDB files in non-user directories wouldn't have to be
> >>  world-writable. This is a bigger security issue than becoming root to
> >>  write them, in my opinion.
> >
> >This has been fixed in HEAD.  I added some code to correct this problem
> >a few weeks ago.  Please check it out, and let me know what you think.
> 
> Joe, correct me if I'm wrong, but I thought you did this for ~user 
> directories only. In fact, I just checked the HEAD from a couple of 
> days ago, and new files are created with mode 666.

Correct, this is only for user directories.

> 
> What I'm proposing is that the files be owned by root (or some other, 
> single user) for non-user-home-directory .AppleDBs also. That way 
> they could be set to mode 600.

I agree.

Joe

>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Marcus Clarke | 2 Oct 2002 01:17
Favicon

Re: [Netatalk-admins] Re: Netatalk 1.5.5 released

On Wed, 2002-09-25 at 09:03, didier wrote:
> Joe Marcus Clarke wrote:
> > On Tue, 24 Sep 2002, Steve Freitas wrote:
> > 
> > CNID works, but I have had zero feedback on CDB.  I need more people to
> > test the CDB code to see if we should switch over to this style.
> Work here, but it's not under load. With ro volume I have a lot of
> cnid_mangle_get: Failed to find mangled entry for ....

This may be "normal."  I toned down the logging, but I haven't taken
full advantage of some of loggers features.

Joe

> eg in :AppleVolumes.default
> /usr/share/doc doc options:ro dbpath:/tmp
> so the cnid is rw
> 
> Didier
> 
> 
--

-- 
PGP Key : http://www.marcuscom.com/pgp.asc
Permalink | Reply | 1 comment |
headers
Harald Wagener | 2 Oct 2002 11:27

Switch to 1.5.5 and multiple servers on one machine

Hello list,
I successfully upgraded to the recently released netatalk-1.5.5 and my 
users are quite happy about it, except for one thing:

Originally, I defined more than one server in afpd.conf (clients; 
archive; fonts; other_small_company). After the switch to 1.5.5, I 
still can connect to archive, fonts, and other_small_company (running 
on ports 12000, 12001, and 12002 respectively), but the volumes defined 
in AppleVolumes.archive; AppleVolume.fonts and 
AppleVolume.other_small_company don't show up again.

Has anything changed in the afpd.conf syntax? It worked until the 
switch (last night) without flaw.

Regards,
	Harald
--

-- 
Harald Wagener * FCB/Wilkens * An der Alster 42 * 20099 Hamburg
Permalink | Reply | 0 comments |
headers
Harald Wagener | 2 Oct 2002 17:49

cnid problems after server crash

Hello,
due to a hardware problem on my RAID system, I had to boot my server 
without being able to umount the data partition. Appletalk was stopped.

I run netatalk-1.5.5 with cnid. The users can mount shares, but don't 
see data (which I verified being there by sshing into the box and 
looking at the data directly).

cnid_maint give the following output:

[root <at> fileserver1 bin]# ./cnid_maint -?
Unknown option: ?
Beginning run of CNID DB Maintanence script at Wed Oct  2 17:46:03 2002.

INFO: Running db_recover on /mnt/files/mac-only/.AppleDB
WARNING: Failed to run db_recover on /mnt/files/mac-only/.AppleDB
INFO: Running db_recover on /mnt/files/mac-only/.AppleDB
WARNING: Failed to run db_recover on /mnt/files/mac-only/.AppleDB
INFO: Running db_recover on /mnt/files/mac-only/.AppleDB
WARNING: Failed to run db_recover on /mnt/files/mac-only/.AppleDB
INFO: Running db_recover on /mnt/files/austausch/.AppleDB
WARNING: Failed to run db_recover on /mnt/files/austausch/.AppleDB
INFO: Running db_recover on /mnt/files/austausch/.AppleDB
WARNING: Failed to run db_recover on /mnt/files/austausch/.AppleDB
INFO: Running db_recover on /mnt/files/austausch/.AppleDB
WARNING: Failed to run db_recover on /mnt/files/austausch/.AppleDB
INFO: Running db_recover on /mnt/files/clients/.AppleDB
WARNING: Failed to run db_recover on /mnt/files/clients/.AppleDB
INFO: Running db_recover on /mnt/files/clients/.AppleDB
WARNING: Failed to run db_recover on /mnt/files/clients/.AppleDB
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joe Marcus Clarke | 2 Oct 2002 18:00
Favicon

Re: cnid problems after server crash

On Wed, 2002-10-02 at 11:49, Harald Wagener wrote:
> Hello,
> due to a hardware problem on my RAID system, I had to boot my server 
> without being able to umount the data partition. Appletalk was stopped.
> 
> I run netatalk-1.5.5 with cnid. The users can mount shares, but don't 
> see data (which I verified being there by sshing into the box and 
> looking at the data directly).
> 
> cnid_maint give the following output:
> 
> [root <at> fileserver1 bin]# ./cnid_maint -?
> Unknown option: ?
> Beginning run of CNID DB Maintanence script at Wed Oct  2 17:46:03 2002.
> 
> INFO: Running db_recover on /mnt/files/mac-only/.AppleDB
> WARNING: Failed to run db_recover on /mnt/files/mac-only/.AppleDB
> INFO: Running db_recover on /mnt/files/mac-only/.AppleDB
> WARNING: Failed to run db_recover on /mnt/files/mac-only/.AppleDB
> INFO: Running db_recover on /mnt/files/mac-only/.AppleDB
> WARNING: Failed to run db_recover on /mnt/files/mac-only/.AppleDB
> INFO: Running db_recover on /mnt/files/austausch/.AppleDB
> WARNING: Failed to run db_recover on /mnt/files/austausch/.AppleDB
> INFO: Running db_recover on /mnt/files/austausch/.AppleDB
> WARNING: Failed to run db_recover on /mnt/files/austausch/.AppleDB
> INFO: Running db_recover on /mnt/files/austausch/.AppleDB
> WARNING: Failed to run db_recover on /mnt/files/austausch/.AppleDB
> INFO: Running db_recover on /mnt/files/clients/.AppleDB
> WARNING: Failed to run db_recover on /mnt/files/clients/.AppleDB
> INFO: Running db_recover on /mnt/files/clients/.AppleDB
(Continue reading)

Permalink | Reply | 1 comment |

Gmane