Re: Passwordless Authentication (was Re: How to reduce sid security)
On Fri, Aug 01, 2003 at 11:04:32AM +0200, Kjetil Kjernsmo wrote: On Friday 01 August 2003 04:10, Peter Cordes wrote: You should use ssh-keygen to create a keypair on each machine, and copy the public key from the machine you generated it on to the other machine. This allows quick passwordless authentication. I've tried to do this many times, but I've failed... Is there a Very Verbose Guide to Passwordless Authentication with SSH somewhere...? :-) There are few different ones linked from http://www.openssh.com/press.html HTH, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passwordless Authentication (was Re: How to reduce sid security)
On Fri, Aug 01, 2003 at 11:04:32AM +0200, Kjetil Kjernsmo wrote: On Friday 01 August 2003 04:10, Peter Cordes wrote: You should use ssh-keygen to create a keypair on each machine, and copy the public key from the machine you generated it on to the other machine. This allows quick passwordless authentication. I've tried to do this many times, but I've failed... Is there a Very Verbose Guide to Passwordless Authentication with SSH somewhere...? :-) There are few different ones linked from http://www.openssh.com/press.html HTH, Rob
Apache user pages (was: Re: Permissions on /root/)
On Sat, Mar 08, 2003 at 08:16:38PM +0100, Thomas Sj?gren wrote: On Sat, 8 Mar 2003, Birzan George Cristian wrote: It should be locked down and not touched by adduser (Would You Like To Make All Homedirs World-Readable?). root is not the regular user. Users need o+x on their home dirs for Apache to be able to serve pages. No they don't. You shouldn't place user websites in their home dirs. Place the user webspace in e.g /var/www/[user] and symlink from public_html or whatever. ..and this makes a difference how...? I'm not necessarily trying to disagree with you, I was just expecting an explanation as to why that is a better solution. Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Apache user pages (was: Re: Permissions on /root/)
On Sat, Mar 08, 2003 at 08:16:38PM +0100, Thomas Sj?gren wrote: On Sat, 8 Mar 2003, Birzan George Cristian wrote: It should be locked down and not touched by adduser (Would You Like To Make All Homedirs World-Readable?). root is not the regular user. Users need o+x on their home dirs for Apache to be able to serve pages. No they don't. You shouldn't place user websites in their home dirs. Place the user webspace in e.g /var/www/[user] and symlink from public_html or whatever. ..and this makes a difference how...? I'm not necessarily trying to disagree with you, I was just expecting an explanation as to why that is a better solution. Rob
Re: [OT] please do not ...
On Sat, Nov 16, 2002 at 11:55:49AM +0100, poczta wrote: people, do not respond to 'unsubscribe' messages, 'cause from on mail it grows to many messages, so think twice before you mail on it. thanks or at the very least, If you are bound and determined to address this person's erorr, reply to person's individual email address, not the list. If they are trying to unsubscribe, odds are they don't read the list mail anyway. That way you avoid spamming more junk to the list and probably educate the person than just complaining about them in a forum where they'll likely never hear it. This last unsubscribe thread did actually end up with some useful information though - a changed subject would have been a good thing. Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] please do not ...
On Sat, Nov 16, 2002 at 11:55:49AM +0100, poczta wrote: people, do not respond to 'unsubscribe' messages, 'cause from on mail it grows to many messages, so think twice before you mail on it. thanks or at the very least, If you are bound and determined to address this person's erorr, reply to person's individual email address, not the list. If they are trying to unsubscribe, odds are they don't read the list mail anyway. That way you avoid spamming more junk to the list and probably educate the person than just complaining about them in a forum where they'll likely never hear it. This last unsubscribe thread did actually end up with some useful information though - a changed subject would have been a good thing. Rob
Re: Some more port closing questions
On Tue, Jul 30, 2002 at 01:22:50PM -0400, Phillip Hofmeister wrote: On Tue, 30 Jul 2002 at 11:09:49AM -0600, Crawford Rainwater wrote: Thanks to all on the Portsentry issue I had a week ago. Along those same lines, I have two ports I cannot figure out (even looking through the LDP) on how to close or shut down their related services. They are as follows: 111/tcp sunrpc 111/udp sunrpc I believe there is something in /etc/init.d/mountnfs* that deals with this (portmap) Actually in woody, portmap is its own package, so if you don't need it, just remove the package. Rob
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote: Hi all Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? Not sure if you've seen this, but the maintainer offers an explanation in /usr/share/doc/ssh/README.Debian.gz Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SSH RSA Authentication
I am trying to use RSA authentication between different machines, but
I'm running into trouble between machines running different versions of
ssh.
Machine A is running unstable with OpenSSH 3.0.2p1, and it is trying to
connect to machine B running stable, with a compiled from source ssh,
version 3.2.3p1.
On machine A, I run ssh-keygen, and generate an identity and
identity.pub. I copy identity.pub to ~/.ssh/authorized_keys on Machine
B, but it still prompts for the system password, not my keyphrase. I
notice that B's more recent ssh-keygen insists I use the -t flag to
specificy key type, so I then generate another key on machine A with
'ssh-keygen -t rsa', creating id_rsa and id_rsa.pub, and proceed to copy
id_rsa.pub to Machine B's authorized_keys file. Still no luck, same
regular password prompt.
To convince myself that I'm not doing something completely wrong, I
generate keys on Machine B ('ssh-keygen -t rsa'), and copy the public
key to Machine C (virtually identical machine running same version of
OpenSSH) and the key authentication works as expected. :-\
Any ideas as to how to make the different versions understand each
other?
Thanks,
Rob
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH RSA Authentication
On Sat, Jun 22, 2002 at 07:50:07PM +0200, Dietmar Goldbeck wrote: It is very difficult to help you without error messages, since there shouldn't be a problem. openssh 3.0.2 and 3.2.3 play perfectly well with each other. There weren't any error messages, otherwise I would have provided them. Just the behavior I described. I would guess that you are connecting with ssh protocol 1 to a server which has protocol 1 disabled. Nope. The server will authenticate ssh1 clients fine. Try generating new keys for protocol 2 with ssh-keygen -d, copy them with ssh-copy-id and try again. Now that did work. I'm still confused as to why the rsa generated keys didn't. What I did realize is that unstables ssh-keygen creates rsa1 keys for ssh1 by default, which is odd, but still doesn't explain why the explicated stated (ssh2) rsa keys failed. Regardless, thanks for the dsa suggestion, it solves my problem, but I'm still curious as to why the rsa key did not work. Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Wed, Apr 10, 2002 at 12:21:13AM +0100, Gareth Bowker wrote: On Tue, Apr 09, 2002 at 04:02:34PM -0500, Rob VanFleet wrote: On Tue, Apr 09, 2002 at 07:23:28AM -0700, Luca Filipozzi wrote: You run those service locally on each machine only. You don't make them available to other hosts. Sorry if I'm being completely dense here, but aren't the ports still open, even if they are only serving localhost? The point is that it's made accessible only from localhost. Whether this is by using a firewall to block connections from anyone else, using tcpwrappers or that it only binds to the lo interface. This last case (binding to lo): how would I go about doing that? Thanks, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Tue, Apr 09, 2002 at 12:37:27PM +0200, Wichert Akkerman wrote: Previously Alan Shutko wrote: An AFS-based setup is used at many places to great effect, especially on untrusted nets, but I don't know how bad setup is. I suspect it's evil. There is also SFS which works very nicely indeed. After doing some reading about it, the only thing that turns me off to SFS is that you still have to run the usual NFS services for it to work. A large part of the reason I am seeking alternatives is that those services are so often vulnerable. Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Tue, Apr 09, 2002 at 07:23:28AM -0700, Luca Filipozzi wrote: On Tue, Apr 09, 2002 at 06:51:38AM -0500, Rob VanFleet wrote: After doing some reading about it, the only thing that turns me off to SFS is that you still have to run the usual NFS services for it to work. A large part of the reason I am seeking alternatives is that those services are so often vulnerable. You run those service locally on each machine only. You don't make them available to other hosts. Sorry if I'm being completely dense here, but aren't the ports still open, even if they are only serving localhost? Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Tue, Apr 09, 2002 at 12:37:27PM +0200, Wichert Akkerman wrote: Previously Alan Shutko wrote: An AFS-based setup is used at many places to great effect, especially on untrusted nets, but I don't know how bad setup is. I suspect it's evil. There is also SFS which works very nicely indeed. After doing some reading about it, the only thing that turns me off to SFS is that you still have to run the usual NFS services for it to work. A large part of the reason I am seeking alternatives is that those services are so often vulnerable. Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Tue, Apr 09, 2002 at 07:23:28AM -0700, Luca Filipozzi wrote: On Tue, Apr 09, 2002 at 06:51:38AM -0500, Rob VanFleet wrote: After doing some reading about it, the only thing that turns me off to SFS is that you still have to run the usual NFS services for it to work. A large part of the reason I am seeking alternatives is that those services are so often vulnerable. You run those service locally on each machine only. You don't make them available to other hosts. Sorry if I'm being completely dense here, but aren't the ports still open, even if they are only serving localhost? Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
NFS, password transparency, and security
I have a situation where my superiors are leaning heavily on me to make life more convenient for them by having total availability of data from a group of machines. They basically want to log into any one machine within this group with the same password, and be able to access any disks they choose from any pariticular machine (within this group). What makes me nervous is that is that I have little to no control over the network. The particular setup at our university is that every single ethernet drop has a unique and world accessible IP (most of this is done with DHCP, so most change, but the machines that have purposes, like the afformentioned group - don't). These machines also share subnets with machines I don't control, which makes using non-encrypted authentication even more dangerous than usual - it is a switched network, but that doesn't protect against much at all. The best I can do to keep these machines from being affected from the world is to have iptables firewalls set up on each of them, basically denying everything including pings from outside specified subnets. This is a less than desirable solution, not to mention the scalability issues inherent with every single machine having its own set of firewall rules. What I am curious to know what is the best way possible to implement what they want and to do so as securely as possible. I work for several University astronomers who basically want something like what they're used to at other places: a pure sun shop, running NIS and NFS. While I'm aware that this can be done just as easily with Linux, I am going to assume that many places who run NIS/NFS do so inside a strictly internal network, not on several Machines that have external IPs to themselves on subnets shared by student lab machines and other untrusted nodes. What I have done so far is just have a few users's home directories mounted over NFS on a central machine, making sure that they have the same UIDs across the board. I am rapidly realizing that this solution does not scale well, plus it does not provide a full solution. I apologize in advance for any rambling or over-generalizations. Please add any advice or corrections you may have. Thanks, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 07:39:43PM -0700, Luca Filipozzi wrote: Two choices for authentication (passwd + shadow): (1) Kerberos Never used it. Can't advise you. I've looked at Kerberos, but at least a cursory glance at leaves the impressions that it is ridiculously complicated to set up and requires multiple servers. If someone has used it and can correct me, please do. (2) LDAP Use LDAP (recompile --with-tls flag) + libpam-ldap + libnss-ldap to do the equivalent of NIS but securely. Without using SSL or Kerberos, would LDAP still be sending passwords across the net in plain text? [...] Several choices for file sharing: (1) NFS + iptables + tcpwrappers Doing that right now. (2) SFS (see sfs-server sfs-client packages and www.fs.net) Requires users to authenticate against the file server, also. Consider using libpam-sfs (I'm rewriting it as we speak.) (3) OpenAFS (see openafs-fileserver + openafs-client) Also requirres users to authenticate against the file server, but when used in a Kerberos environment, you only have to logon once due to Kerberos' ticket-granting system. Both of these sound very promising. I had heard of AFS before, but not SFS. I'll have to research them further. I'll probably have even more questions after that though. :) Hope this (probably incomplete) list helps, Immensely. Thanks for the information. Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
NFS, password transparency, and security
I have a situation where my superiors are leaning heavily on me to make life more convenient for them by having total availability of data from a group of machines. They basically want to log into any one machine within this group with the same password, and be able to access any disks they choose from any pariticular machine (within this group). What makes me nervous is that is that I have little to no control over the network. The particular setup at our university is that every single ethernet drop has a unique and world accessible IP (most of this is done with DHCP, so most change, but the machines that have purposes, like the afformentioned group - don't). These machines also share subnets with machines I don't control, which makes using non-encrypted authentication even more dangerous than usual - it is a switched network, but that doesn't protect against much at all. The best I can do to keep these machines from being affected from the world is to have iptables firewalls set up on each of them, basically denying everything including pings from outside specified subnets. This is a less than desirable solution, not to mention the scalability issues inherent with every single machine having its own set of firewall rules. What I am curious to know what is the best way possible to implement what they want and to do so as securely as possible. I work for several University astronomers who basically want something like what they're used to at other places: a pure sun shop, running NIS and NFS. While I'm aware that this can be done just as easily with Linux, I am going to assume that many places who run NIS/NFS do so inside a strictly internal network, not on several Machines that have external IPs to themselves on subnets shared by student lab machines and other untrusted nodes. What I have done so far is just have a few users's home directories mounted over NFS on a central machine, making sure that they have the same UIDs across the board. I am rapidly realizing that this solution does not scale well, plus it does not provide a full solution. I apologize in advance for any rambling or over-generalizations. Please add any advice or corrections you may have. Thanks, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 07:39:43PM -0700, Luca Filipozzi wrote: Two choices for authentication (passwd + shadow): (1) Kerberos Never used it. Can't advise you. I've looked at Kerberos, but at least a cursory glance at leaves the impressions that it is ridiculously complicated to set up and requires multiple servers. If someone has used it and can correct me, please do. (2) LDAP Use LDAP (recompile --with-tls flag) + libpam-ldap + libnss-ldap to do the equivalent of NIS but securely. Without using SSL or Kerberos, would LDAP still be sending passwords across the net in plain text? [...] Several choices for file sharing: (1) NFS + iptables + tcpwrappers Doing that right now. (2) SFS (see sfs-server sfs-client packages and www.fs.net) Requires users to authenticate against the file server, also. Consider using libpam-sfs (I'm rewriting it as we speak.) (3) OpenAFS (see openafs-fileserver + openafs-client) Also requirres users to authenticate against the file server, but when used in a Kerberos environment, you only have to logon once due to Kerberos' ticket-granting system. Both of these sound very promising. I had heard of AFS before, but not SFS. I'll have to research them further. I'll probably have even more questions after that though. :) Hope this (probably incomplete) list helps, Immensely. Thanks for the information. Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: scp and sftp
On Mon, Apr 01, 2002 at 10:35:35AM -0500, Jon McCain wrote: But changing permissions on the .bash_profile so they don't own it (and not in their group) should take care of that problem. They can read it all they want, just not change it. A cleaner solution would be to make it immutable. (as root): chattr +i .bash_profile HTH -Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: scp and sftp
On Mon, Apr 01, 2002 at 10:35:35AM -0500, Jon McCain wrote: But changing permissions on the .bash_profile so they don't own it (and not in their group) should take care of that problem. They can read it all they want, just not change it. A cleaner solution would be to make it immutable. (as root): chattr +i .bash_profile HTH -Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/passwd as shell
On Thu, Jan 24, 2002 at 07:23:35AM +0100, martin f krafft wrote: also sprach Rob VanFleet On this list (I beleive) I saw someone mention the use of /bin/passwd as a shell for mail-only users so they can easily change their password without having to ask someone. Is this a secure option, or am I missing some glaring problems? If so, what are some other possible solutions? that was me, and no, noone has mentioned any bad aspects yet, other than your users having to type the old password twice. however, it's not the solution i amlooking for, so i am implementing a highly secure way to do it over and SSL/TLS-encrypted webform with emphasis on minimization of root privilege needs. i'll post to the list when i am done. Thanks, that would be great. I thought about some sort of CGI for that as well, but without spending more time on it than I have at the moment I figured it would be far less secure than a password-protected passwd. :) With proper taint checking it would probably be a better option. -Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/passwd as shell
On Thu, Jan 24, 2002 at 07:23:35AM +0100, martin f krafft wrote: also sprach Rob VanFleet On this list (I beleive) I saw someone mention the use of /bin/passwd as a shell for mail-only users so they can easily change their password without having to ask someone. Is this a secure option, or am I missing some glaring problems? If so, what are some other possible solutions? that was me, and no, noone has mentioned any bad aspects yet, other than your users having to type the old password twice. however, it's not the solution i amlooking for, so i am implementing a highly secure way to do it over and SSL/TLS-encrypted webform with emphasis on minimization of root privilege needs. i'll post to the list when i am done. Thanks, that would be great. I thought about some sort of CGI for that as well, but without spending more time on it than I have at the moment I figured it would be far less secure than a password-protected passwd. :) With proper taint checking it would probably be a better option. -Rob
/bin/passwd as shell
On this list (I beleive) I saw someone mention the use of /bin/passwd as a shell for mail-only users so they can easily change their password without having to ask someone. Is this a secure option, or am I missing some glaring problems? If so, what are some other possible solutions? Thanks, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BugTraq Kernel 2.2.19
On Fri, Oct 19, 2001 at 12:24:45PM -0500, Kenneth Pronovici wrote: i think Linus has already approved the patch. im not sure yet when will it arrive though.. Yes, the email linked to by that /. posting : http://www.securityfocus.com/cgi-bin/archive.pl?id=1mid=221337start=2001-10-15end=2001-10-21 has attached to it the Linus-blessed 2.2.19 patch. Has anyone else noticed that the included exploit does not affect 2.2.19? I tested it on one of my boxes and got the expected 'Operation not permitted'. Maybe I'm misunderstanding the problem, but I thought taht 2.2.19 took care of (well hindered) the ptrace problems. -Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BugTraq Kernel 2.2.19
On Fri, Oct 19, 2001 at 12:24:45PM -0500, Kenneth Pronovici wrote: i think Linus has already approved the patch. im not sure yet when will it arrive though.. Yes, the email linked to by that /. posting : http://www.securityfocus.com/cgi-bin/archive.pl?id=1mid=221337start=2001-10-15end=2001-10-21 has attached to it the Linus-blessed 2.2.19 patch. Has anyone else noticed that the included exploit does not affect 2.2.19? I tested it on one of my boxes and got the expected 'Operation not permitted'. Maybe I'm misunderstanding the problem, but I thought taht 2.2.19 took care of (well hindered) the ptrace problems. -Rob
LogCheck Issues
I seem to be having a small problem with something in the logcheck.ignore file. The default setup for the logcheck package under debian already contains this entry in logcheck.ignore to avoid reporting this common cron job: /USR/SBIN/CRON\[.*\]: (mail) CMD ( if \[ -x /usr/sbin/exim \]; then /usr/sbin/exim -q /dev/null 21; fi) which works fine, but there is another very similar (but different) cron job that also runs which isn't caught by the above regex and is reported by logcheck as an Unusual System Event. Here is one example: /USR/SBIN/CRON[4922]: (mail) CMD ( if [ -x /usr/sbin/exim -a -f /etc/exim.conf ]; then /usr/sbin/exim -q /dev/null 21; fi) So I added the following regex to catch it: /USR/SBIN/CRON\[.*\]: (mail) CMD ( if \[ -x /usr/sbin/exim -a -f /etc/exim.conf \]; then /usr/sbin/exim -q /dev/null 21; fi) (after simply trying to add a '.*' between '/usr/sbin/exim' and ']' unsuccessfully) but to no avail. I still recieve warnings about it, even though I believe I am properly covering it. Does anyone have an idea what I might be doing wrong? Thanks, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
LogCheck Issues
I seem to be having a small problem with something in the logcheck.ignore file. The default setup for the logcheck package under debian already contains this entry in logcheck.ignore to avoid reporting this common cron job: /USR/SBIN/CRON\[.*\]: (mail) CMD ( if \[ -x /usr/sbin/exim \]; then /usr/sbin/exim -q /dev/null 21; fi) which works fine, but there is another very similar (but different) cron job that also runs which isn't caught by the above regex and is reported by logcheck as an Unusual System Event. Here is one example: /USR/SBIN/CRON[4922]: (mail) CMD ( if [ -x /usr/sbin/exim -a -f /etc/exim.conf ]; then /usr/sbin/exim -q /dev/null 21; fi) So I added the following regex to catch it: /USR/SBIN/CRON\[.*\]: (mail) CMD ( if \[ -x /usr/sbin/exim -a -f /etc/exim.conf \]; then /usr/sbin/exim -q /dev/null 21; fi) (after simply trying to add a '.*' between '/usr/sbin/exim' and ']' unsuccessfully) but to no avail. I still recieve warnings about it, even though I believe I am properly covering it. Does anyone have an idea what I might be doing wrong? Thanks, Rob
Re: Mutt and inline gpg
On Thu, Aug 09, 2001 at 05:26:50PM +0200, Christian Kurz wrote: option pgp_create_traditional. That option might help you very much, but instead I would suggest that the other MUA's get fixed. Um, wouldn't that be every other MUA asid from mutt and maybe one or two others? -Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mutt and inline gpg
On Thu, Aug 09, 2001 at 05:26:50PM +0200, Christian Kurz wrote: option pgp_create_traditional. That option might help you very much, but instead I would suggest that the other MUA's get fixed. Um, wouldn't that be every other MUA asid from mutt and maybe one or two others? -Rob
Re: --no-run option (was: Re: red worm amusement)
Exactly. It is more of a special case to *not* want a server to start at boot rather than the other way around. To those who think that apt-get install apache is too easy, then why is apt-get remove apache too hard? -Rob On Sun, Jul 22, 2001 at 04:00:43PM +0200, Bernhard R. Link wrote: On Sun, 22 Jul 2001, Steven Barker wrote: I think that there should be a way to install a debian server packages without having the installation scripts start the server. This need not be default, but it should be possible. Why should anyone want to install a server without letting it run? The standard-config is normally sane, and when you do not think so, place another config-file there before installing it. ( If you are that paranoic you should not only do ar -x xxx.deb ; tar -xzf data.tgz etc/configfile , but also check the whole package before installing it). would download, install and configure apache, but not run it. When the sysadmin was satisfied with the configureation files, etc, then update-rc.d and such could be run by hand (or by another call to apt-get/dpkg with another flag). Not adding rc.d-Links is really ridicilous. If you have an computer, that justs boots after installing without the chance to change links, than you should plug-out the network-cable so or so. This would have to be both a policy change and a technical change in apt and/or dpkg. I think it would be a good compromise between security and the simplicity of apt-get install foo. I do not see a nesecarity for it. Though if you want to supply patches to carry an --no-run in dpkg to some environment-variable to the script and and patch to dh_xxx to check this, go ahead, but there are important and senseful thing to do. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-get install apache (was red worm amusement)
On Sun, Jul 22, 2001 at 07:28:31PM -0500, Kenneth Pronovici wrote: If you're upgrading for security and bug fixes, you use upgrade. In michael's defense, take this entry from the apt-get mapage: dist-upgrade dist-upgrade, in addition to performing the func tion of upgrade, also intelligently handles chang ing dependencies with new versions of packages; ^^^ Yes, but when you're upgrading your existing packages, and the dependencies have changed to such a degree to require *new* packages, that almost always implies a major change, such as a stable - testing transition, not a security fix for a package in stable (which is what security.debian.org is for). Upgrade does exactly as it implies, it upgrades your existing packages, and under no circumstances installs anything new, avoiding the whole I tried to upgrade to some security fixes and ended up with XFree86 and KDE issues. -Rob apt-get has a smart conflict resolution system, and it will attempt to upgrade the most important packages at the expense of less important ones if necessary. The /etc/apt/sources.list file contains a list of locations from which to retrieve desired package files. I agree we all need to know the tools we use, and I'll be the first to admit that I have learning to do too, just like michael. However, the manpage is where I start... and when I read this, it sure seemed like a good idea to use dist-upgrade rather than upgrade. Maybe I should have dug deeper to be sure, but... KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] Personal Homepage: http://www.skyjammer.com/~pronovic/ I have zero tolerance for zero-tolerance policies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: red worm amusement
On Sat, Jul 21, 2001 at 07:52:02PM -0700, Jacob Meuser wrote: And whose going to teach them? Certainly not an OS that makes it as easy as 'apt-get install apache' ! Well, your solution of making it more obfuscated and difficult will cause even more of a problem. Many new users will simply say This is annoying, I'll install PWS on my Windows box instead. Now which is more of a 'danger'? -Rob
Re: apt-get install apache (was red worm amusement)
On Sun, Jul 22, 2001 at 07:59:47AM -0500, chandler wrote: Similarly, after a recent apt-get dist-upgrade (intended to grab security updates only, Then why did you dist-upgrade? I think it's pretty self-explanatory that if you're upgrading from one distribution to another (like from stable to testing) you use dist-upgrade. If you're upgrading for security and bug fixes, you use upgrade. so should I remove the non security.debian.org URLs from /apt/sources?) No, just don't use dist-upgrade and make sure all of your sources are pointing to the correct distribution of Debian you are tracking. on my firewall box, I somehow managed to get all of X windows installed and a copule of services I didn't want installed AND started AND added to /etc/rc*.d. Thankfully X windows still requires startx to get going, but the services (junkbuster and wwwoffle) were just there. And while reboots on that machine are limited to power outages, it's still extra work to administer that stuff into the 'off' position. apt-get remove junkbuster wwwoffle --purge Not so hard to me. To me the lack of warnings or configurability during an apt-get install for a service is a questionable practice. Have you ever bothered to lower your message priority in debconf? dpkg-reconfigure debconf. Choose 'low'. Learn about the tools before you start to criticize them. -Rob
Re: --no-run option (was: Re: red worm amusement)
Exactly. It is more of a special case to *not* want a server to start at boot rather than the other way around. To those who think that apt-get install apache is too easy, then why is apt-get remove apache too hard? -Rob On Sun, Jul 22, 2001 at 04:00:43PM +0200, Bernhard R. Link wrote: On Sun, 22 Jul 2001, Steven Barker wrote: I think that there should be a way to install a debian server packages without having the installation scripts start the server. This need not be default, but it should be possible. Why should anyone want to install a server without letting it run? The standard-config is normally sane, and when you do not think so, place another config-file there before installing it. ( If you are that paranoic you should not only do ar -x xxx.deb ; tar -xzf data.tgz etc/configfile , but also check the whole package before installing it). would download, install and configure apache, but not run it. When the sysadmin was satisfied with the configureation files, etc, then update-rc.d and such could be run by hand (or by another call to apt-get/dpkg with another flag). Not adding rc.d-Links is really ridicilous. If you have an computer, that justs boots after installing without the chance to change links, than you should plug-out the network-cable so or so. This would have to be both a policy change and a technical change in apt and/or dpkg. I think it would be a good compromise between security and the simplicity of apt-get install foo. I do not see a nesecarity for it. Though if you want to supply patches to carry an --no-run in dpkg to some environment-variable to the script and and patch to dh_xxx to check this, go ahead, but there are important and senseful thing to do. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: red worm amusement
On Sat, Jul 21, 2001 at 07:52:02PM -0700, Jacob Meuser wrote: And whose going to teach them? Certainly not an OS that makes it as easy as 'apt-get install apache' ! Well, your solution of making it more obfuscated and difficult will cause even more of a problem. Many new users will simply say This is annoying, I'll install PWS on my Windows box instead. Now which is more of a 'danger'? -Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
