[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-users] moving users from group to another group
- Subject: Re: [cobalt-users] moving users from group to another group
- From: "Julius" <lists@xxxxxxxx>
- Date: Thu Jun 6 09:48:00 2002
- List-id: Mailing list for users to share thoughts on Sun Cobalt products. <cobalt-users.list.cobalt.com>
>> Jeff L. wrote:
> My recollection is you made a post showing it (or parts of it)
> were empty when you looked. Have you done meta-verify on it? Do
> you know it's good?
Long ago I ran meta-verify on it, meta-verify creates entries
for the virtual site(s) in the httpd.conf file, but it also
pulls data out of httpd.conf, the document root, and
NameVirtualHost if they are there, which I have discovered,
for some strange reason were not in the correct format.
NameVirtualHost was simply not even in there anymore
(which explains the missing fqdn), and document root
for the 1st virtual site had been changed by hand
(due to the webmail program (Squirrel), so it
obtained a wrong location for the /users directory
and some related issues. From then on the GUI has
slowly been 'corrupted' with faulty entries.
Basically this is what I need to do;
1. Change to httpd.conf back to the orignal state
(to what the RaQ ui created it as)
2. Drop the entry in postgres's vsite table which points
this to site1 or the default site (I need to decide on that)
3. Re-run meta-verify and probably check virtusertable
and maybe shadow and password files for wrong group entries
for some user (the ones created after or during the time
the faulty postgres existed, some are in group 112, while
they should be in 100).
> You're using a Raq in an environment it really isn't designed for;
> that's okay, but it may cause you "issues" downstream.
Well, I've done it before, with a RaQ3, and never
had any problems with it running webmail and email.
(in fact; you will not find a smarter solution for the same price).
I don't see why a RaQ4i could not be used as a dedicated
webmail and email server. You can patch things along the way,
and never have issues downstream. So far it's running like
a charm, by the way, no problems whatsoever anywhere, no
strange memory leaking, none of that. The only problem
is the admin GUI not being able to change site settings
(and therefore not being able to add users or email-aliases).
>> The RaQ4 is in 'production' as we speak,
>> restoring it would mean a lot of things; The failoverserver
>> to work en be there (right now it isn't, thanks to KPNQwest),
>
> Fixable, I presume.
I don't think it will be soon, http://www.ams-ix.net/news.html
not all bb-providers are that confident, so they cut off
their connection to KPNQwest's network.
> Actually pretty easy; linux system admins do this sort of work,
> both planned, and unplanned under pressure, all the time.
Linux is not a Cobalt RaQ4i. They sure don't do it in a way
that each user has a correct entry in the postgres database.
>> Putting those accounts, passwords, and aliases back
>> the way they are now would be an impossible task,
>> and require the exact same misery to go through
>> where I'm going through right now.
>
> Not really; you can save backups of the files they're in, and
> manually restore them later, then run meta-verify to restore the
> PostgreSQL database.
Well, that is what I'm doing, so your point is?
> But you'd only have to do it once and then the system would work.
> If you don't give us enough details then of course we can't
> suggest anything to help you.
Here's what I need to know:
What files hold the user and site defaults and
how to change them using the commandline, or if
that is not an option; what to hexedit in them to get
those settings to be different from what they are now.
I've already discussed my problem with Jeff Bilicki
(the shell tool guy), if I have the user and site settings
changed, i can enter a user using the GUI again, as soon
as the GUI has updated the databases the correct way,
I can change quota, recreate a database to work with,
etc. Right now I simply can't even create the base
for a good recovery of it.
> I thought we went over this before; I still think it's because the
> quotas are set to 0 because of an error in postgreSQL data.
It's been set to the defaults, which is 5 MB/user,
and it's been switched off entirely by me using quotaoff.
0 means "Unlimited", or so I've read from those dreaded man pages.
--
Julius