Re: Etch security updates
Milan Melichercik wrote: >Lennart Sorensen wrote: > > >>On Thu, May 25, 2006 at 10:19:57AM +0100, Birju Prajapati wrote: >> >> >>>Hi, >>>I'm trying to track down security updates for etch on AMD64 for my >>>sources.list. >>>The following entry does not seem to work: >>>deb http://security.debian.org/ etch/updates main contrib non-free >>>Giving the error: >>>Failed to fetch http://security.debian.org/dists/etch/updates/Release >>>Unable to find expected entry main/binary-amd64/Packages in >>>Meta-index file (malformed Release file?) >>>And as expected, the Release file has no amd64 entry. Is there a plan >>>to include AMD64 security updates in the etch package repository? Or >>>am I just looking in the wrong place? >>> >>>Thanks in advance, >>> >>> >>The directory does not exist. It does for sarge. Could it be that no >>etch security fixes have been made since amd64 packages started to enter >>etch? >> >>Len Sorensen >> >> > >As far as I know the security updates for testing branch go through unstable >branch with maximum priority (approx. 2 days till they get into the testing). >If I'm wrong, please, correct me. > > > There have been several security updates during this week alone, there should be some available for amd64. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ldap problem
>> There's definately some duplicates (tty, nobody, etc). But I'm not sure what will happen if I take those out, the ldap server being in production and all.. >>> >>>Is this wise? I ask, because I honestly don't know. I would assume that >>>this >>>is a bad idea. I would think there should be no possible dupblicate user >>>mappings. Something is bound to get confused. In general I also think that >>>there is probably no reason whatsoever to share system user account >>>information >>>anyway. Each machine should handle system accounts locally. System group >>>information seems a bit trickier, though, since system group membership >>>information would not be shared. We recently got into trouble because we had two "nobody" users which had different primary groups, this broke mailman. The second nobody was added by smbldap-tools. So I guess having duplicate, unconsistent users is a bad idea, altough having identical users shouldn't be a problem, if you keep them updated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
