|
|
| Author |
Message |
| 25 new of 467 responses total. |
cross
|
|
response 253 of 467:
| 
Oct 24 19:22 UTC 2004 |
Why not use PostgreSQL instead of MySQL and be happy? And what's wrong
with TWiki? That, to my knowledge, doesn't require a SQL RDBMS.
|
aruba
|
|
response 254 of 467:
|
Oct 24 19:24 UTC 2004 |
The inventory database is written to MySQL, so we need to have that whether
or not we have PostgreSQL. (I understand it's already there; Jan is talking
about the PHP interface to these databases, I think.)
|
cross
|
|
response 255 of 467:
|
Oct 24 22:42 UTC 2004 |
Yes, Jan is referring to the latter. However, it was my understanding
that the inventory database was for msql, which is again a different
beast (and much older and less widely used). It'd require some tweaking
to get running under either; I'd prefer to see it go to pgsql instead
of mysql if work hasn't already been done.
Regardless, TWiki doesn't need an RDBMS, and it uses CVS for versioning.
I'd say let's try that instead of mediawiki.
|
janc
|
|
response 256 of 467:
|
Oct 24 23:59 UTC 2004 |
I got php to work correctly by installing it from the package instead from
the ports tree. I should probably do more package installs instead of ports
installs. But they are in some ways clumsier to use.
It turns out I didn't have mysql fully installed - I only had the client and
not the server. I got it fully up and configured. Invent uses MySQL, not
msql. Nuget uses msql, and will need to be replaced.
Neither mediawiki nor anything else that we now have requires postgreSQL.
I'll probably uninstall it. I expect we'll be using MySQL for many things.
I got mediawiki working, but I'm not very happy with it. It is rather
stupidly configured, with the file containing the MySQL database password
residing under the document route. It's a .php file, so you shouldn't be
able to see the source under ordinary circumstances, but why put it there
in the first place. I'm not entirely happy at the idea of having the Grex
Staff Collective Memory buried in a database that can only be easily read
via this particular application. If apache, php, mysql and the wiki aren't
all working, you can't read it. There're a couple other things I don't much
like about it either. Which is too bad. I like way it looks from the
outside.
Maybe I'll look at twiki.
|
janc
|
|
response 257 of 467:
|
Oct 25 00:05 UTC 2004 |
Looks like Twiki is based on RCS not CVS. Written in Perl. Might be a better
fit.
|
mfp
|
|
response 258 of 467:
|
Oct 25 01:46 UTC 2004 |
Point.
|
gelinas
|
|
response 259 of 467:
|
Oct 25 02:30 UTC 2004 |
The new grex machine's name is grease.cyberspace.org. Is that the name people
are using? Is that the name giving DNS trouble?
At least once a day, I check the name server on grex (dns.cyberspace.org) to
make sure it's offering up information. Occasionally, I check some of our
secondary name servers, as well. I've not noticed any problems yet. Despite
the fact that named is restarting and dumping core (probably not in that
order) frequently.
|
janc
|
|
response 260 of 467:
|
Oct 25 02:50 UTC 2004 |
Which named is doing that? On nextGrex?
I uninstalled mediawiki and php. I installed Twiki. I haven't figured it
out, but I have the impression it will do the job.
I set it up to authenticate out of /etc/passwd, just like backtalk. However,
it still kind of wants you to register.
Ideally I'd set up a Staff Web that can only be modified by staff. Possibly
there would be some pages in that that could only be read by staff. Don't
really know how to do this though. Don't really want to spend the time
figuring it out right now either. Should get back to working on more critical
things.
If any other staffers want to test this, it's at
http://grease.cyberspace.org/twiki/bin/view/
|
gelinas
|
|
response 261 of 467:
|
Oct 25 02:58 UTC 2004 |
The named on the current grex, Jan. I should probably take a look at the one
on grease, too.
|
mfp
|
|
response 262 of 467:
|
Oct 25 03:01 UTC 2004 |
Trying 216.93.104.38...
Connected to grease.cyberspace.org.
Escape character is '^]'.
OpenBSD/i386 (grex.cyberspace.org) (ttyp3)
User not authenticated. Using plaintext username and password
login: newuser
Password:
Login incorrect
|
naftee
|
|
response 263 of 467:
|
Oct 25 05:14 UTC 2004 |
savage.
|
cross
|
|
response 264 of 467:
|
Oct 25 05:30 UTC 2004 |
Oh, is it really RCS? Tom Limoncelli lied to me.
|
naftee
|
|
response 265 of 467:
|
Oct 25 05:30 UTC 2004 |
What do you get when you cross a Lemon and a Cello ?
|
tod
|
|
response 266 of 467:
|
Oct 25 05:31 UTC 2004 |
There's always room from JELL-O!
|
tod
|
|
response 267 of 467:
|
Oct 25 05:33 UTC 2004 |
I'd be glad to test connectivity from Seattle..
|
naftee
|
|
response 268 of 467:
|
Oct 25 05:37 UTC 2004 |
Doesn't traceroute do that for you?
|
mfp
|
|
response 269 of 467:
|
Oct 25 05:50 UTC 2004 |
Point.
|
naftee
|
|
response 270 of 467:
|
Oct 25 05:57 UTC 2004 |
Point.
|
mfp
|
|
response 271 of 467:
|
Oct 25 06:45 UTC 2004 |
Point.
|
gelinas
|
|
response 272 of 467:
|
Oct 25 12:18 UTC 2004 |
The named on grease has been up and running since the last reboot.
|
mfp
|
|
response 273 of 467:
|
Oct 25 17:55 UTC 2004 |
Point.
|
naftee
|
|
response 274 of 467:
|
Oct 25 19:56 UTC 2004 |
soup@m-net-bash-2.05a$ ft grease:
FrontTalk 0.3.2
Copyright 2001, Jan Wolter
Connect to 'grease' failed.
Unknown system 'grease'.
:(
Point.
|
mfp
|
|
response 275 of 467:
|
Oct 25 20:06 UTC 2004 |
Point.
|
gelinas
|
|
response 276 of 467:
|
Oct 26 04:34 UTC 2004 |
It took a bit longer than I expected in #198 above, but I've begun updating
the web pages on the new grex machine. I started with faq.html.
Has java been installed?
|
janc
|
|
response 277 of 467:
|
Oct 26 05:38 UTC 2004 |
I don't think Java has been installed.
I think I need to take a little vacation from nextGrex work. I'm tired. I
have other things I want to work on. And the level of incivility around here
is sapping my enthusiasm. I need to work on something that gives me some
pleasure for a bit.
Need to figure out log rolling. The log rolling program on nextGrex is called
newsyslog. It gets run by cron and is configured through newsyslog.conf.
Need to figure out if all log files are included (things like the newuser logs
probably aren't) and figure out how often to roll each log and how long to
keep them for. Probably whatever is being done on old Grex is a template to
emulate. Some logs we want to keep forever, including newuser logs.
I think configuring the log rolling is the single most important task that
still needs to be done before a switch over.
The 'zapuser' and 'lockuser' commands need more testing. Zapuser has not been
tried on large sets of users, nor has the directory deletion (-d option) been
tested. Note that lockuser doesn't 'x' passwords - instead it expires the
account, since this is more easily reversable.
The birthday wisher hasn't been ported, though login does print out the
birthday motd.
Someone needs to comb through /usr/local/bin on Grex and make sure that
everything there has been ported. I've run across a few things that hadn't
been just at random, and suspect there may be more.
/usr/local/grexdoc probably needs to be moved over.
I wasn't sure that login was correctly reporting counts of failed logins, like
"there have been 15 failed attempts to log into your account since the last
time you tried". Both telnet and ssh should be reporting these.
Generally more testing of everything would be good.
Things that can probably slide till after we change over:
There's something that looks like source to Marcus's fork bomb killer in
Dan Cross's home directory on nextGrex. It'd be nice if that could be
ported into the OpenBSD kernel. It shouldn't be awfully hard.
Need to work out a spam filtering strategy.
Robocop needs more testing and tuning - figuring out what thresholds to set
on numbers of processes and amount of memory to use before knocking out a
user. Probably someone should test out some forkbombs and such.
When changeover day comes, there are tools for renumbering gid and uid
numbers on files moved over from old Grex that Dan wrote and I documented
and slightly fixed in ~janc/regroup
Can't think of anything else.
|
