response 100 of 137:

Jul 31 22:07 UTC 1995

        Of course not.

response 102 of 137:

Aug 1 04:29 UTC 1995

Use the    last    command, piping the output through something that
parses & collects it.  I once wrote a nawk script to do this, a few
years back.  Various other people have done similar things.  (How far
back does our wtmp file go these days?)

response 104 of 137:

Aug 1 21:23 UTC 1995

Sorry, davel, but I'm not able to use the last command, no matter
how helpful it might be, not to mention piping it, because I don't
know that much Unix.
        Can anyone help us out here by answering my question in #101?
All I'm looking for is some simple, comparable measure of the number
of users per month (or whatever) over a period of a year.

response 106 of 137:

Aug 2 14:30 UTC 1995

In 101 you asked aboout the "number of users" figure. It is the number
of accounts as given by the line count of the file /etc/passwd, which is
reaped continuously, removing accounts inactive for more than 90 days.

Therefore it includes all accounts for which there has been activity in
the last 90 days.

You also asked "Is there any way to tell how the number of users during a
 time period (e.g., a month) has changed over the past year or so?"

Davel gave the best answer to that in 102. We don't have any tools ready
to do this at the moment that I know of.

response 108 of 137:

Aug 13 11:21 UTC 1995

It still seems that we are drifting ofthe subject of whether grex
should try to migrate to an intel platform, or stay with a Sun
platform?

Has anyone addressed the question yet about whether grex wants to stay
``single super machine'' centric, or whether we want to move to a
distributed platform?  In this question, I think lies the answer to
the question about what architecture we will use in the future.  If we
decide to stay with a single super machine, then the sun platform is
clearly the way to go.  But if we decide that it is time to stop
sinking money into Fraken-grex, then we should start considering ways
of transistioning into distributed, low-end pc network.

There are multipl advantages to the distibuted environment:

  * Fress OS (BSD386 and Linux)
  * Cheap, easily replacable parts.
  * System redundency.
  * Severe reduction in the number of Single Points of Failure.
  * Less off-hours system support (Who cares if one out of 20 machines
       is unreachable...)

Someone compared sun and intel to a mercedes and chevette.  I will
agree that the mercedes is a better car, but If I can get 20 chevettes
or one mercedes, and my goal is to move loads of people, I will opt for
the chvettes anytime.  If the mercedes can go twice as fast, that means
I will can move 10 times the amount of people.  And if a chevette
breaks, then I still have 19 others.  And I never have to special order
a part for a chevette with the Auto Store right on the corner...

Of course, there is a drawback to having multipl machines in a
distributed environment.  SysAdm time gets exponetially more demanding.
Not only is it harder to secure the systems, but you have so many more
machines that require the "basic" servicing that, with the current
abilities of the staff, I do not think that grex would be able to
survive.

Kinda of a catch 22 situation. no matter how you look at it.

response 110 of 137:

Aug 13 13:47 UTC 1995

Greg.  You are right that I have not set up a distributed system by
myself before, but I am trying to learn the correct ways of doing
things.  One of the things that you learn early on is that if you have
more then a handful of users, it is time to start thinking of ways to
share the load.  Of course, the people that are going to fight you are
the been-counters and the SysAdm's.  (Bean counters say what we have is
good enough, and the SysAdm's refuse to do the work required to make
the system work.  I have to deal with both of these types of people in
my office.  They are bribing me to be quiet with the promise of getting
me my own ibm rs6000 to use.  But that is of no consequence.)

But what I have learned from working with the AOL and ISC machines is
that, as dificult as it may be, a distributed system is what is needed
to be able to effectively run a multi-user service like what grex wants
to offer.

I will agree with you that, definately, the sun's are a better choice.
But I think that you are putting the intel systems into a far worse
light then they deserve.  I have talked to quite a few local isp's
that are using intel stuff with one of the free OS's.  So it can be
done.  (isp == internet service provider)

Of course, I would not trust NFS for anything more then I would have to.
(Say two single user machines on private lan, but even that is pushing
the usefulness of NFS.)  What you want to do is have a system that uses
an authentication system like kerberos to allow you access to the
different services.  (It is real easy to offload things like picospan,
party, news, mail, irc, web type clients, et al., to seperate machines
when you have a secure authentication system like kerberos.  The hard
part is having the user home space set up correctly.  But if you
offload the cpu intensive programs like the above list, then you can use
the single login machine for  a while longer.  At least till you are
comfortable with a distributed file system.  (NFS over an encrypted
kerberized rsh would be cool.)

Of course, the problems still lie with man power and sysadm ability.
Making such a large change is really, really hard...

But that is just my opinion...  :)

response 112 of 137:

Aug 14 00:54 UTC 1995

Greg,  If it seems that we are attacking you (the sysadm group) or even
talking negatively about you, then I apologize about the
miscommunication.  I personally feel that you are doing a tremendous
job keeping a system like grex up and running with only volunteer
support.  I have found the sysadm on grex to be more responsive then
any other environment/community that I have been involved in.  So,
please do not take the discussion as a personal insult.

It seems to me that this discussion is talking about the future of
grex, and not the present day realities.  It seems that the phase
``sun4'' upgrade is in its final drawing board status and is about
ready to be implemented.  I have not seen anyone say that this should
not happen.  With it being so close to being done, it would be
disastrous for it not to happen.  It also seems that there very well
might be a few more phases of upgrades before any thought could/should
be put into a change of platform is considered.

Plus, I think that the question that is being debated is unfair.
Talking about sun vs intel is very premature.  The first thing that
needs to be decided is what grexs future system reqirements will be.
Then decide how those requirements should be met.

That is why I brought up the idea of distributed environment .vs.
single mega-machine.  Thinking about this makes us think about what we
will need the system for.  If we can figure that out, we can then
figure out how to implement those needs.  And part of figuring out how
to implement the needs is to decide what platform to use.

---

Now some technical comments.

Greg, if you are uncomfortable with using the intel free OS's, maybe we
can create a 'test' for one.  I have seen items where there has been
talk of grex either getting an ISDN connection, or switching providers.
That means that the router that is currently in use will need to be
upgraded.  I have been told that gryps is a 386 running a ka9q os on top
of dos.  This might be ok for the link that we have now, but it should
be considered not so good for any future connections.

What I would recommend is upgrading the router to have a Free unix OS,
then compile gated for the os.  After you have a working gated, you can
then talk one of the current routing protocols with the provider (iBGP
in particular.)  Once you have this up and running, you would have a
production box that has the potential OS of the future on it so that we
could watch for any bugs to crop up.

It would at least be a start...

...

Hmmm.  Maybe I am to late with this suggestion.  It seems that grex is
already taking a different path then the last time I checked.

16  ici-um.cic.net (198.87.206.6)  84 ms  67 ms  69 ms
17  ef1.valley.r.ic.net (152.160.68.253)  66 ms  65 ms  69 ms
18  valley1.t.ic.net (152.160.1.17)  68 ms  68 ms  67 ms
19  152.160.82.254 (152.160.82.254)  205 ms  209 ms  208 ms
20  grex.cyberspace.org (152.160.30.1)  211 ms  209 ms  208 ms

Are we already connected to the freenet thing that I saw discussed
somewhere else?

response 114 of 137:

Aug 14 03:08 UTC 1995

Gryps is the name of Grex's router.  It is running FreeBSD.

response 116 of 137:

Aug 14 03:33 UTC 1995

Gryphs was running NetBSD, but NetBSD has *serious* bugs in it's tty
drivers that caused it to lunch itself about every 1 to 4 hours on average.
We gave up on NetBSD and switched to FreeBSD, whcih has *much* better tty
drivers, but gryphs still manages to hang at least once or twice a day.
And all it's doing is routing, imagine what would happen if it was also
serving 50 users!

response 118 of 137:

Aug 14 04:16 UTC 1995

If you type !ttyuse it will give you a graph of all the tty usage that day
(I think).

response 120 of 137:

Aug 14 09:09 UTC 1995

We arn't running gated on gryphs. We have 3 machines with well defined
IP addresses. gated is a PITA to setup and it is overkill for our situation.
We just have a pair of static routes. 50 users is the normal max load that
the Sun-3 handles every evening during the busy hours. Any machine that
would replace it, would have to be able to deal with that many users at once.
Like scg said, run ttyuse. It gives a nice graphical view of the day's use.

response 122 of 137:

Aug 14 11:09 UTC 1995

Or passing out in the 3000degree heat in the dungeon. :-)

response 124 of 137:

Sep 17 20:25 UTC 1995

Re #121:  Only 32 modems?  We go from one login and one router to 16 assorted
boxes, and only double the number of modems?

Re #0:  sidhe had one theory as to why members are leaving, and claimed that
he wasn't the only one to feel that way.  He made his case, as far as I am
concerned.  *I* don't feel that way, and most of the users and members don't
(that's why they still ARE users/members), but SOME ppl feel that way.  That
explains few of the defections, imho:  does anyone else have theories?  Have
we attempted to contact former members to ascertain their reasons for leaving,
or have we just let them go?  That would seem to be a logical course.

danr says some ppl can only log on at night,  which is then our slowest time;
I have found, however, that the slowest time (over the net, maybe that makes
a difference?) is during the workday; If I forget and call during the day,
I am quickly reminded of my error by the slowness in acheiving a connection
with Grex.

he also raised the specter once again of replacing Pico:  wasn't YAPP proposed
at one point?  Should we consider that?  Should we try to find something else
entirely?  commission mdw to release a new version of Pico?  throw a lot of
support to the Webspan project and push that?

Let's get back to the idea of a mission statement, maybe even start a new item
for JUST that.  It's always easier to reach  your goals if you have some, and
know what they are.  It's going to be rather difficult for me to get a job
in a few months when I graduate, if I don't have a clearer idea by then of
what I would like to do.  Similarly, Grex will just muddle along, upgrading
occaisionally, maybe even zigzagging a bit, unless they/we periodically
reconsider what, exactly, we are trying to do.

(btw, what happened to this item, it hadn't been touched in over a month
before I started this response?)