Re: Accounts on debian.org machines
On Mon, 8 Dec 2003, Matthew Garrett wrote: Steve Langasek wrote: But an ssh key on removable media is not vulnerable to keysniffing alone, where a password is. There's no inherent increase in security from using a key on a USB device other than the fact that attackers aren't thinking about that yet. Cryptographic smart cards on a USB token seem like the only secure way to store keys: http://www.datakey.com/products/smartCards/ikey.shtml Niall YoungChime Communications Pty Ltd [EMAIL PROTECTED]Level 6, 263 Adelaide Terrace Ph: (+61) 08 9213 1330 / 0408 192 797 Perth, Western Australia 6000 I was trying to kill a level 5 lumberjack in the MUD I play -- Travis Read, August 2003
Re: [custom] Debian Enterprise - a Custom Debian Distribution
On 2 Dec 2003, Zenaan Harkness wrote: - debconf package configurations (with enterprise defaults) To me this is still the largest hurdle, having to work around packages that don't yet use debconf, and not easily being able to take a debconf snapshot and apply it to another host. Being able to do a Noninteractive install of every package in Debian, pre-seeding debconf, or even a separate Debian registry if debconf isn't meant to work like this, so you could replicate a system 100% accurately. Even being able to apply a new debconf/registry profile and then asking all packages to reconfigure, that would be impressive. Then it's just a matter of customising anything not handled completely by debconf with, if you will, flavour-postinst etc. in a metapackage or udeb or flavour/class definition. Flavours could consist only of Debian packages from the archive, plus this freely shared metapackage. Perhaps this could even replace the task system eventually, including postinst commands etc. All of the value adding that flavours can provide will be in that last stage, modifying the default configuration, adding pretty interfaces or whatever.. Maybe the terms I've used are incorrect, I'm only vaguely familiar with metapackages/udeb etc. but you get the idea. Flavours simply become a wrapper or d-i hook performed after package installation, to utilise and remain 100% Debian. Perhaps the flavour definition is hosted in the archive and policy compliant, perhaps not. Building live CDs and non-interactive installs are relatively straightforward, but will remain a hack and a maintainer nightmare until the infrastructure enables and supports them imho. Niall YoungChime Communications Pty Ltd [EMAIL PROTECTED]Level 6, 263 Adelaide Terrace Ph: (+61) 08 9213 1330 / 0408 192 797 Perth, Western Australia 6000 Are you a parent who would like to involve your kids in an iiNsanity event? -- Jodie Evans, Mar 2003
Re: postrm::downgrade?
On Wed, Jul 02, 2003 at 03:18:36PM +0800, Niall Young wrote: I'm using a custom package pool for deploying software, but we need to cleanly rollback if an upgrade doesn't go as expected. In easy cases it is possible to first test a package with some testing machine and only put in in the used archive when it suites your needs. Agreed, I meant in *addition* to pre-deployment testing - say if testing didn't pick up all bugs and you discover fatal problems post deployment. How about a postrm::downgrade hook to reverse any changes made in the new version's preinst::upgrade so that when the old version's preinst::upgrade is applied you're not left with a potential mix of configuration? seamlessly - i.e. reverse all changes made in the upgrade. Is there another way? You'd need more than that. Apt would need to be changed to handle undoing of package splitting (Conflicts/Replaces), and is not always possible anyway, new packages, might use new file-formats which can be converted from the old-version but not back again. Yeah - it's a minefield of nightmares I know. Debian handles upgrades really well, but downgrades aren't as seamless. A postrm::downgrade hook is a pretty major change, it would take years to roll out - just wondering if anyone has thought about the problem before and if/when Debian could address this? A remove and clean install seems to be the only option which is unfortunate. Something to think about at least... Niall YoungChime Communications Pty Ltd [EMAIL PROTECTED]Level 6, 263 Adelaide Terrace Ph: (+61) 08 9213 1330 / 0408 192 797 Perth, Western Australia 6000 donate to our Charity of the month which is the Eating Disorders Association of WA Inc. ... give a gold coin donation and I'll reward you with nice sweet chocolate! M -- Jodie Evans, Feb 2003
postrm::downgrade?
I'm aware you can downgrade packages with `apt-get --force-yes install package=version-revision` but this doesn't seem to apply any postrm processing on the existing version of the package being replaced. How about a postrm::downgrade hook to reverse any changes made in the new version's preinst::upgrade so that when the old version's preinst::upgrade is applied you're not left with a potential mix of configuration? I'm using a custom package pool for deploying software, but we need to cleanly rollback if an upgrade doesn't go as expected. Removing the package entirely and reinstalling isn't an option, it needs to be done seamlessly - i.e. reverse all changes made in the upgrade. Is there another way? Niall YoungChime Communications Pty Ltd [EMAIL PROTECTED]Level 6, 263 Adelaide Terrace Ph: (+61) 08 9213 1330 / 0408 192 797 Perth, Western Australia 6000 donate to our Charity of the month which is the Eating Disorders Association of WA Inc. ... give a gold coin donation and I'll reward you with nice sweet chocolate! M -- Jodie Evans, Feb 2003
Automated network installs?
I'm about to start work on a tool to automate network Debian installs, possibly using a library of images (and eventually tools to create and maintain those images), or by using a profile of packages to install. I've been looking at mondo and replicator, but they're not quite what I need. Is there anything similar being worked on already, or any recommendations on what the ideal method would be? I'd prefer the Packages/config profile, and use a central repository, but security will be an issue (may use readonly filesystem, would prefer to look into verifying checksums and comparing to a trusted source). Mondo's CDR method is nice from the security perspective, but I want a bit more control over the config of individual machines. Does this need a new tool, or should I add this functionality to the install process (load a profile before dselect, not sure what tool suggests the current profiles when installing?). Pre-defining configs is vital though - I want to automate everything, basically create hundreds of identical machines with maybe a dozen local changes such as IP. Will debconf help out here? I'm new to Debian, any advice or comments appreciated. No point reinventing the wheel. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
qmail
What's the official stance on qmail? Is the licence (or lack thereof?) too restrictive (any modified versions can't be distributed without approval)? I notice that qmail-src_1.03-14.deb and qmail_1.03-14.dsc are in non-free - any reason that binary packages haven't been made (yes I know that qmail-src comes with compile scripts)? Any issues or opinions on qmail? I've recently migrated from RedHat (and loving it) and while I'd prefer to stick with what Debian officially recommends, qmail has some features that I prefer. Anyone got any good arguments against qmail? -- [EMAIL PROTECTED]
