Hi all,

    First, excuse me, but the link not worked properly. I can't download the file.
    Second, I appreciate your try to create sql version of ippool module (btw, why
    it not process accounting on/off packets - recieving this packet RADIUS server
    should mark all IPs as deallocated?).
> 2. We use transaction so could not use rlm_sql, instead rlm_sql source
> is included. This is bad.
    Why not using rlm_sql? I think any tries to implement rlm_sql module/driver
    specially for this module will be ugly. If it not have transactions implemented,
    then we have reason to implement it rlm_sql in the interface calls. Anyway,
    if it's not currently possible we can create rlm_sqlippool without transactions.
    I have my own idea about DB's scheema for this module. Maybe somebody like it.
    Datatypes from Postgresql, but you can adopt to any other RDBMS.

        ippools
        -------
        poolname    text
    This table just store set of ippool names. This table optional and have only
    informational usability.

        ipranges
        ----------
        poolname    int4
        rangeid     int4
        rangefrom   inet
        rangeto     inet
        netmask     inet
    This relation store ranges of IP addresses for each ippool. netmask field
    have the same meaning, as in rlm_ippool module. NB: one pool can have
    multiple ip ranges!

        allocatedips
        ------------
        ip                  inet
        nasipaddr           inet
        nasport             int4
        callingstation      text
    _Global_ store for allocated IPs. NB: different ippools can have the same
    or overlapped ipranges without any problems, because we have global store.
    Last tree fields used for the same aims, as on rlm_ippool (for deallocation
    on accounting stop,on,off-packets). Now about transactions - you can not
    to use transations if you create unique index on ip attribute! RDBMS will
    fail to allocate the same IP - and you'll just should properly interpret
    this by trying allocation of another IP address.
        Thanks a lot for any comments.



--
 best regards,
Ruslan A Dautkhanov   [EMAIL PROTECTED]

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to