RE: [cobalt-users] moving users from group to another group

["Peter Masloch" <peter@xxxxxxxxxxx>]

Julius,
your server is a frick'n mess. Here is what you should do:
borrow another Raq from somewhere, move everything over,
then re-install the OS on your server and move everything
back to your. You can do that with a downtime from
maybe 10 minutes.
If you don't do this, your server will crash very soon.




> Jeff L. wrote:
> 
> > The postgreSQL database is bad; I thought we'd agreed on 
> that a long 
> > time ago;
> 
> Do you mean it is something which will always be bad
> in your opinion, or in this case has gone bad?
> I was never saying it wasn't, I know it is,
> but it isn't as bad as you think it is, it only
> has a couple of bad entries that need to be rebuilt
> along the way.
> 
> > I believe I've previously recommend a complete
> > system restore; you've decided that's not viable for you,
> 
> If you would know my situation, you would not be restoring 
> either. It simply is not an option. The RaQ is doing 
> dedicated webmail and email mostly. Why it is not serving 
> many websites is besides the point, it can be used this way 
> and it was the best option in this particular case. The 
> amount of webmail and email users is that large, a Qube (for 
> example) wouldn't cope with it that easy.
> *they* decided to buy a RaQ4i, after my advice to do so.
> 
> First; I can't switch off the admserv, users need to be able
> to change their passwords by use of the GUI, which works
> nicely right now. 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), 
> to have all user data (user prefs/mail etc.) backed up the 
> way it is now and be put back the way it is now, which can't 
> be done; The GUI stopped functioning BEFORE anybody knew, so 
> a lot of things have been done with somehow non-functional 
> postgres and sendmail databases. 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. So the only option 
> is to re-create the postgres databases in a way that the GUi 
> will show the default site again.
> 
> > you've spent more time than that by now.
> 
> No I haven't. You just don't know the details involved.
> Doing a restore would imply exactly what I'm doing right now.
> 
> >> since I've done a quotaoff for /dev/hda4 and
> >> cobalt's postgresql need at least some quotum,
> >> it can't work without one.
> >
> > I don't think it's working now.
> 
> Well I'm still getting quota warnings over email
> from the machine. Also, when creating a user using
> (c)adduser, I can;t because the user quota is reset
> the wrong way for the default user/site settings.
> 
> > Do you want to turn off the Cobalt gui entirely and run the box 
> > completely manually?  If you do, let me know; I have some notes on
> that somewhere.  But if so you won't be able to use any of the
> > Cobalt tools; not even the cobalt/adduser.
> 
> Like I wrote: It would be better if Sun Cobalt had created
> a graphic interface for the shell, to function as a
> complete backup for the GUI.
> 
> >> the main trouble is; editing site quota/settings
> >> through use of the commandline seems impossible.
> >
> > Why?  Because the Cobalt system is somehow overriding them?  You
> can fix that by deleting the Cobalt gui, if you really don't 
> want to use it.
> 
> No, I would need to delete the postgres databases,
> and, as explained before, that is not an option;
> They're not broken by themselves, the only thing broken
> here is what's inside them.
> 
> > My first guess is that the domain isn't properly
> > recognized in the local-host-names file or is incorrectly listed in 
> > access file, or you've changed these manually and not 
> either rebuilt 
> > the database or restarted sendmail as required.  But it could be 
> > something else entirely, including a DNS error.
> 
> DNS errors are out, that I know in this case.
> Note that I know this exact same erratic behavior
> on RaQs WITHOUT ever having touched the shell.
> There's a lot of talk about the 'bug' on the raqfaq pages.
> It has to do with the order in which you enter domains
> and their aliases etc. This, in my opinion, is simply
> faulty design by Cobalt.
> 
> > See above, but you really do have to know
> > what you're doing with sendmail.
> 
> Why are you so bound on people needing to 'learn' things
> before they can solve their problems? It is totally 
> unnecessary, especially in this case, to 'know what you're 
> doing with sendmail'. I don't even have to configure sendmail 
> in any other way than it has been thus far. It might be 
> better for Sun to find a way to create an update pkg for 
> sendmail, since we're behind a long way when using a RaQ with 
> the version of sendmail currently on it.
> 
> > As long as you realize it won't any longer be running as a RaQ, but 
> > rather as some kind of hybrid,
> 
> Why would it be? It hasn't changed a thing if I'm back
> at what it was like and have the GUI working again.
> 
> > I know several people who've successfully run RaQs without 
> a virtual 
> > site,
> 
> well, go check the admin site for a RaQ4i, create NO
> virtual site and then hope it will receive email for
> more than one domain name on that default site,
> by only using the GUI. I wish you luck.
> 
> > and there's no reason why the RaQ "sauce" requires one.
> 
> Well I've discovered that it does.
> Try to add users without there being a virtual domain name.
> 
> > I don't know what
> > originally caused your problem, and I understand you cannot use it 
> > now, but that doesn't mean it can't be used by anyone else.
> 
> >From what I've read the past years, I'm not the only one having
> problems with the default site next to virtual site config
> on a Cobalt RaQ.
> -- 
> Julius
> 
> 
> _______________________________________________
> cobalt-users mailing list
> cobalt-users@xxxxxxxxxxxxxxx
> To Subscribe or Unsubscribe, please go to: 
> http://list.cobalt.com/mailman/listinfo/cobalt> -users
> 
>