Exporting

[Ivan Kohler]

On Wed, Jun 23, 1999 at 08:22:27AM -0700, Joel Griffiths wrote:
> On Wed, 23 Jun 1999, Ivan Kohler wrote:
> > On Wed, Jun 23, 1999 at 02:25:34AM -0600, Ben Leibig wrote:
> 
> BTW, for RedHat, I had to modify the svc_acct->check as follows:
>     if ( $recref->{username} eq 'sync' ) {
>       $recref->{shell} = '/bin/sync';
>     }
>     elsif ( $recref->{username} eq 'shutdown') {
>       $recref->{shell} = '/sbin/shutdown';
>     }
>     elsif ( $recref->{username} eq 'halt') {
>       $recref->{shell} = '/bin/halt';
>     }
>     else {
>       my($shell);
>       if ( $shell = (grep $_ eq $recref->{shell}, @shells)[0] ) {
>         $recref->{shell} = $shell;
>       } else {
>         return "Illegal shell ". $self->shell;
>       }
>     }
> 

Could you have added /bin/sync, /sbin/shutdown, and /bin/halt to the
`shells' configuration file before importing, and removed them afterwords?
(even better if svc_acct.import did that automatically - it could just
munge and restore @FS::svc_acct::shells... hmm.)

> > MHO is to import first.  The socratic question I'd ask about what you plan
> > to do is "How do you prevent duplicate usernames?"
> Or duplicate User ID's for that matter.....
> 
> BTW, Ivan, I am trying to verify in an additional database table that a
> particular user doesn't exist. This database is used to store email aliases and
> additional POP boxes for our customers (kinda like AOL allows). I have toyed
> with the idea of just writing the aliases to an email only svc_acct that
> doesn't write to the password file, but that isn't really how I want to do it.

Actually, I think that's a pretty good way to do it.  Cerkit contributed
support a little while back for svc_acct.pm and svc_acct.export for
multiple export targets.  It needs to be cleaned up and documented, which
I'll try to get to soon.  For this to work correctly, the svc_acct_sm
table should go away, along with the concept of a "default" domain.

> What I want to do is verify that the information isn't in this secondary table.
> I tried to use the qsearchs but it complains that it doesn't recognise the
> table name. I'm not much with OO stuff, but I am learning fast. You wouldn't
> have any quick hints as to how I would easily go about this, do you. I am sure
> I'll figure it out sooner or later, but I figured I would ask since I am here.
> :-)

Freeside has a layer on top of the SQL database, so in addition to adding
the table to the SQL database, you need to: 

- run bin/dbdef-create to update the meta-data FS::dbdef stores about the
database (tables, columns, keys, indices).

- create a class for this table, FS::table_name. 
site_perl/table_template.pm and/or site_perl/table_template-svc.pm should
help you with this.  use FS::table_name; at the top of the file you are
searching in. 

Searches will probably work even if you don't do the second step, but they
will emit a slew of warnings (a stack backtrace every search).  There's a
cluck in FS::Record::qsearch.

-- 
Ivan Kohler <ivan at sisd.com> - finger for PGP key - <moc.dsis at navi> Relhok Navi
Open-source billing and administration for ISPs - http://www.sisd.com/freeside
20 4,16 * * * saytime # please don't be surprised if you find me dreaming too