Tomasz,
Below is the <authreg/> section of my c2s.xml.  

>So, if you intent to get JIDs of your users from DB, you should better
>rely on "active" table.

Good to know.  Can you tell me by what mechanism the JIDs get entered into the 
active table?

---------------------   begin authreg ------------------------

<!-- Authentication/registration database configuration -->
  <authreg>
    <!-- Backend module to use -->
    <module>pam</module>

    <!-- Registration configuration -->
    <register>
      <!-- Account registration is enabled by default (provided the
           auth/reg module in use supports it). Comment this out to
           disable. -->
       <!-- <enable/> -->

      <!-- Human-readable instructions to be returned to client when
           registration is requested. 
      <instructions>Enter a username and password to register with this 
server.</instructions> -->

      <!-- Password change only. When registration is disabled, it may
           still be useful to allow clients to change their password. If
           you want this, uncomment this when you disable registration. -->
      <!--
      <password/>
      -->
    </register>

    <!-- Available authentication mechanisms -->
    <mechanisms>

      <!-- These are the traditional Jabber authentication mechanisms.
           Comment out any that you don't want to be offered to clients.
           Note that if the auth/reg module does not support one of
           these mechanisms, then it will not be offered regardless of
           whether or not it is enabled here.

           Similarly, if <zerok/> is disabled, then zero-knowledge data
           will not be created when a user is registered. -->
      <traditional>
        <plain/>
        <digest/>
        <zerok/>
      </traditional>

      <!-- SASL authentication mechanisms. Comment out any that you
           don't want to be offered to clients. Again, if the auth/reg
           module does not support one of these mechanisms, then it will
           not be offered. -->
      <sasl>
        <plain/>
        <digest-md5/>
        <!--
        <anonymous/>
        -->
      </sasl>

    </mechanisms>

    <!-- MySQL module configuration -->
    <mysql>
      <!-- Database server host and port -->
      <host>localhost</host>
      <port>3306</port>

      <!-- Database name -->
      <dbname>jabberd2</dbname>

      <!-- Database username and password -->
      <user>jabberd2</user>
      <pass>bogus</pass>
    </mysql>

    <!-- PostgreSQL module configuration -->
    <pgsql>
      <!-- Database server host and port -->
      <host>localhost</host>
      <port>5432</port>

      <!-- Database name -->
      <dbname>jabberd2</dbname>

      <!-- Database username and password -->
      <user>jabberd2</user>
      <pass>bogus</pass>
    </pgsql>

    <!-- Berkeley DB module configuration -->
    <db>
      <!-- Directory to store database files under -->
      <path>/usr/local/jabberd/var/jabberd/db</path>
      
      <!-- Synchronize the database to disk after each write. If you
           disable this, database accesses may be faster, but data may
           be lost if jabberd crashes. -->
      <sync/>
    </db>

    <!-- LDAP module configuration -->
    <ldap>
      <!-- LDAP server host and port (default: 389) -->
      <host>ldap.example.com</host>
      <port>389</port>

      <!-- Use LDAP v3 if possible. If disabled, v2 will be used.
           Encryption options are only available if v3 is enabled. -->
      <!--
      <v3/>
      -->

      <!-- Encryption. If enabled, this will create an encrypted channel
           to the LDAP server using the LDAP STARTTLS mechanism. -->
      <!--
      <starttls/>
      -->

      <!-- Encryption. If enabled, this will create an encrypted channel
           to the server using the old-style "ldaps://" mechanism. It is
           recommended that you use <starttls/> instead of this. -->
      <!--
      <ssl/>
      -->
      
      <!-- DN to bind as for searches. If unspecified, the searches
           will be done anonymously. -->
      <!--
      <binddn>cn=Directory Manager</binddn>
      <bindpw>secret</bindpw>
      -->

      <!-- LDAP attribute that holds the user ID (default: uid) -->
      <uidattr>uid</uidattr>

      <!-- base DN of the tree. You should specify a DN for each
           authentication realm declared in the <local/> section above,
           by using the realm attribute. -->
      <basedn realm='company'>o=Company.com</basedn>
      <basedn>o=Example Corp.</basedn>
    </ldap>

    <!-- Pipe module configuration -->
    <pipe>
      <!-- Program to execute -->
      <exec>/usr/local/jabberd/bin/pipe-auth.pl</exec>
    </pipe>

  </authreg>

-------------------------------- end authreg -----------------------

-----Original Message-----
From: Tomasz Sterna [mailto:[email protected]] 
Sent: Tuesday, March 16, 2010 6:30 PM
Subject: RE: Jabberd2 MySQL data migration

Dnia 2010-03-16, wto o godzinie 21:14 +0000, Leslie G. Seigneur pisze:
>   Thanks for your reply. Hate to say but I guess that is something I
> am unsure about myself at this point.  We use PAM for authentication
> to LDAP so maybe we do not use the data in authreg at all.  Is it
> possible that a username can be created in authreg when using LDAP
> authentication with no in band registration?  
> 
> Also, if I have an active user who is not in authreg should I consider
> the authreg data to be unreliable?  I am asking because the migration
> script that I was thinking of using does use the authreg username.  

It would be best if you just pasted your <authreg/> section of c2s.xml
(without comments), so I could see what exact authentication schema you
use.

But... unless you have <authreg><module>mysql</... you don't use
"authreg" table at all. It is used only by C2S process.
SM uses "active" table to determine whether the user exists.

So, if you intent to get JIDs of your users from DB, you should better
rely on "active" table.


-- 
To unsubscribe send a mail to [email protected]

N�����r��zǧu���[h���z�v��칻�&ޖ+-���F��

Reply via email to