|
|
| Author |
Message |
| 25 new of 467 responses total. |
blaise
|
|
response 150 of 467:
| 
Oct 6 16:03 UTC 2004 |
Found on the web, on a FreeBSD security list:
...specifying a command to run does ignore UseLogin (and is documented
as such), so you'll get an inconsistent environment because of that when
doing cvs over ssh, as opposed to logging in over ssh.
All in all, the UseLogin option seems to be not very useful, and poorly
implemented. But then, we aren't using OpenSSH-portable (well, not in my
source tree, anyway). These things ought to be checked against -portable
[endquote]
I will point out that the first point applies to any non-shell use of
ssh, presumably including sftp and scp.
|
lorance
|
|
response 151 of 467:
|
Oct 6 20:22 UTC 2004 |
A note about Exim.
I run it at work and have it setup to run as a daemon for incoming mail.
There are times when large amounts of mail come into our server and I
have never noticed any performance hit on any of the other services
running on that server. Exim simply sits in the background collecting
mail and flushing the outbound queue every so often. I run exim with the
options '-bd -q30m'. This makes it a daemon and tells it to start a
queue-runner process every 30 minutes. Since most of the mail here tends
to go out it big batches this works perfectly, you might set it lower
for Grex though. Over all I have never had any problems with Exim.
|
janc
|
|
response 152 of 467:
|
Oct 7 02:30 UTC 2004 |
Jim: I agree that UseLogin is not very useful ... unless you happen to be
hacking login to behave in non-standard ways, and want the same behavior under
ssh. Basically the only thing it is really good for is exactly what we are
doing. I can't think of another use for it.
The inconsistancy problem is actually an advantage. Right now, users who
telnet in and users who ssh in get different environments, because 'login'
and 'sshd' don't intialize the environment in exactly the same way. For
instance, stock OpenBSD 'login' does not set the MAIL environment variable,
but stock OpenBSD 'sshd' does. If we switched to having 'sshd' run 'login'
then the environment would be the same no matter how you connected. This
would introduce a useful consistancy. It does, as you quote noted, introduce
an inconsistancy between how the environment is set up when doing other
commands, like cvs, versus how it is set up when starting a shell, but I think
this is vastly less important to Grex's users than consistancy between
different login methods.
Lorance: Thanks for the data point. That's exactly the way exim is
configured on next Grex now. Exim's config files are complex and if they
built the interpretor badly, it could be quite slow. Without any experience
running it on a busy system, and without having read the source code, I
thought it might prove bad. However, the overall architecture and the
documentation were good enough that I was hoping they coded well too. Sounds
like maybe they did. Good news.
|
janc
|
|
response 153 of 467:
|
Oct 7 02:34 UTC 2004 |
My feeling right now is that I'm going to go ahead with hacking up sshd, and
ignore the UseLogin option. This is a security critical piece of software
and there is a distinct lack of confidence in UseLogin in the air. The
developers of OpenSSH clearly have come to hate it, and appear to be
discouraging it's use, albeit in a sideways manner. I just don't feel right
in putting my faith in it.
|
gelinas
|
|
response 154 of 467:
|
Oct 7 04:12 UTC 2004 |
Might it be worthwhile to pass the question to the OpenSSh developers' list?
I agree that, this time, it makes sense to hack them both. But maybe if the
questions around UseLogin can be answered, it won't be necessary at the next
upgrade.
|
mfp
|
|
response 155 of 467:
|
Oct 7 04:15 UTC 2004 |
Thanks, gelinas! You didn't really help anything, but thanks anyway!
|
naftee
|
|
response 156 of 467:
|
Oct 7 05:43 UTC 2004 |
UYEAH!
|
blaise
|
|
response 157 of 467:
|
Oct 7 13:56 UTC 2004 |
Jan, the comment about "not very useful" was not mine but the message I found
by Googling. I was not trying to discourage using UseLogin, just making sure
that all of the facts were known.
|
albaugh
|
|
response 158 of 467:
|
Oct 7 17:58 UTC 2004 |
Am I correct about the following? Going from Sun hardare / SunOS to Intel /
Linux virtually guarantees that existing binaries won't run on NextGrex.
Therefore programs people have will either have to be recompiled from source
on NextGrex or equivalent Linux binaries found.
|
other
|
|
response 159 of 467:
|
Oct 7 18:50 UTC 2004 |
NextGrex is not running Linux. OpenBSD.
|
blaise
|
|
response 160 of 467:
|
Oct 7 20:38 UTC 2004 |
However, with that substitution, Kevin is correct. Programs will have
to be recompiled from source on NextGrex or equivalent OpenBSD binaries
found.
|
albaugh
|
|
response 161 of 467:
|
Oct 7 20:44 UTC 2004 |
(my ignorance, thinking that OpenBSD was a flavor of Linux)
|
janc
|
|
response 162 of 467:
|
Oct 8 02:24 UTC 2004 |
For the most part, it shouldn't matter. Most of the applications people think
of as being written for Linux will actually compile on most any modern Unix
system, including OpenBSD. Odds are pretty good that fixing a program written
for SunOS to work on OpenBSD will require only very small changes.
|
cross
|
|
response 163 of 467:
|
Oct 8 03:03 UTC 2004 |
I'm strongly opposed to changing either login or sshd; why can't we put
this stuff in the global startup scripts, and then source those from
within the user's dot files? Won't that achieve the same effect for 99%
of users without making changes to the base system.
|
twenex
|
|
response 164 of 467:
|
Oct 8 12:58 UTC 2004 |
Most software intended for redistribution in source form is pretty smart
about compiling itself for a whole range of Unices. Any programs written in
sh, bash, (t)csh, zsh, perl, or python for use on Grex should work pretty
much unaltered on NextGrex. Porting software written by Grexers in C or any
other compiled language for Grex to any BSD (Open, Free, or Net) should be
easier than porting it to Linux or any System V Unix (e.g. Solaris,
HP-UX (?)).
|
keesan
|
|
response 165 of 467:
|
Oct 8 16:01 UTC 2004 |
I compiled links for our SunOS with the help of an expert and it took a few
weeks. OpenBSD would probably be a lot easier to compile for, and the chance
of finding things precompiled can't be any lower than for an old SunOS.
By the way, could someone compile Links2 (with ssl and javascript) for the
next grex? It works for online billing at DTE (local electric/gas company)
where lynx does not. It does tables and frames (both optional). It is still
text, but is menu driven (or use keyboard shortcuts) with no mouse needed.
Lynx is a pain to use with tables and won't do javascript at all.
Also a newer version of Pine would be helpful, set up to use lynx or links
to read HTML and go to embedded URLs in emails. A friend has an ISP account
solely to deal with this HTML stuff (she forwards grex mail to it when needed)
because she cannot figure out how to do it manually with the current pine.
|
twenex
|
|
response 166 of 467:
|
Oct 8 17:22 UTC 2004 |
new versions of MH and zsh would be nice, too, please.
|
aruba
|
|
response 167 of 467:
|
Oct 8 18:48 UTC 2004 |
I'm sure we'll be able to udate almost everything, but please, let's get it
up first and then worry about new software.
|
keesan
|
|
response 168 of 467:
|
Oct 9 13:59 UTC 2004 |
Can we have a big celebratory potluck when the next grex is up?
Any chance of it being for New Year's Day?
|
naftee
|
|
response 169 of 467:
|
Oct 9 20:44 UTC 2004 |
Not a chance.
|
janc
|
|
response 170 of 467:
|
Oct 12 16:01 UTC 2004 |
Login and sshd modifications are installed, tested, and cvs'ed. As I was
working on this, I discovered that I'd been looking in the wrong place for
documentation of the UseLogin option for sshd. It's in sshd_config not in
ssh_config. If you look in the right man page, it is still documented.
So maybe that would have been a better choice, but what I've done is in
and working, so I'm not going to re-examine it right now. Onward!
|
janc
|
|
response 171 of 467:
|
Oct 12 20:40 UTC 2004 |
I'm trying to figure out disk quotas. These are limits on the amount of disk
space that each user can use, enforced by the operating system. Quotas are
on a per filesystem basis, so we will need to set quotas on any filesystem
that users can write to.
As always we will be willing to raise user's quotas upon request.
I'm planning not to use soft quotas - these allow a user to go over quota for
a short period of time. I think they just confuse the issue.
Historically our quota has been 1M per user. We may be able to increase this,
because we have bigger disks now. My plan for now is to leave it at 1M, and
see how things go. Maybe we'll increase it later.
A user's quota on the file system where his home directory is will thus be
1M. His quota on all other home file systems will be zero.
We will need to set quotas on /tmp. What should they be?
/var/tmp also exists. Can we turn this into a symbolic link to /tmp? I don't
really want to set quotas on /var. (Quotas have a performance cost.)
An idea would be to start newusers out with a low quota, say 10K. Bump it
up to 1M after a week. This would stop people from creating a new account,
downloading eggdrop, etc. Might not be worth the effort.
I think I may want to write a custom tool to manage quotas.
|
ryan
|
|
response 172 of 467:
|
Oct 12 23:29 UTC 2004 |
This response has been erased.
|
eprom
|
|
response 173 of 467:
|
Oct 13 02:41 UTC 2004 |
I concur
|
gelinas
|
|
response 174 of 467:
|
Oct 13 03:05 UTC 2004 |
If you haven't yet, you should take a look at /grex/grexdoc/openbsd/09-quotas
If you have, but still have questions, let me know, so that I can take
another stab at making the document clear, please.
I disagree on not having softlimits. A soft limit may permit the current
operation to complete when a hard limit would not. For vandals, it
probably won't make a lot of difference. For other users, it can make
a lot of difference in useability.
Re /tmp, as I wrote in my note on quotas in grexdoc:
} It looks like we may also be able to use quotas to automatically remove
} files from the /tmp directory by setting the soft limit to one and the
} hard limit to zero.
I wish I could I remember why I thought that.
Before you spend too much time rolling your own, you might want to spend
some time with edquota, Jan. It really isn't hard to use.
With enough disk space, quotas, and a regular reap, we can afford to have
folks proving to themselves that we really do know what we are talking
about when we tell them their desired software won't work.
I'll try to make some time to compare the 'disk hogs' list with the lock
log and the list of reaped accounts, to see if I can determine which
IRCers had not been locked but had been reaped.
|
