A typical module would be [module_name] path = /var/rbackup/[module_name] read only = false list = false uid = uiduser gid = gigusers transfer logging = yes log format = [%a] %o %m (%u) %f %l auth users = auth_username secrets file = /etc/rsyncd.secrets incoming chmod = ugo+rwx hosts allow = * When the client connects for the first time the path, rights, rsyncd.secrets an d rsyncd.conf is appended/created automatically. The infomation is obtained from the client. The server would not first check if the module credentials exist, if not, then create and then authenticate (although this is not necessary the first time round) I do not think this is possible with the pre-xfer exec statement.
Created attachment 2247 [details] Demo of automatic module creation using a dummy module In my opinion, it would not make sense for rsync to implement any specific technique for automatic module creation since different administrators will want different techniques. However, it might be useful if rsync had an option to reload rsyncd.conf between finishing the pre-xfer exec and actually entering a module. Then pre-xfer exec would not be too late to automatically create a new module. In the absence of that enhancement, you could have each new client first access a dummy module that triggers the daemon to set up the client's account. I'm attaching a tar file of a daemon installation that demonstrates this technique. A client uploads a file giving its desired username and password to a module called "autouser". In autouser's post-xfer exec, the daemon creates the client's module and updates the rsyncd.conf and rsyncd.secrets. Then the client can perform the real transfer.
Erratum for my demo daemon: the configuration file should set "max connections = 1" with a global "lock file" to avoid tons of nasty outcomes when a client connects in the middle of configuration updating. It might be nice if the daemon placed some kind of advisory read lock on its configuration file while reading the file so that other processes could safely update the file by placing a write lock. Bonus points if the daemon keeps the lock while reading the secrets file so it can avoid reading a secrets file newer than the configuration file.
(In reply to comment #2) > Erratum for my demo daemon: the configuration file should set "max connections > = 1" with a global "lock file" to avoid tons of nasty outcomes when a client > connects in the middle of configuration updating. It might be nice if the > daemon placed some kind of advisory read lock on its configuration file while > reading the file so that other processes could safely update the file by > placing a write lock. Bonus points if the daemon keeps the lock while reading > the secrets file so it can avoid reading a secrets file newer than the > configuration file. > The idea of a dummy module is ideal, otherwise the server is open to abuse for unwanted connections. A wishlist is to have rsync authenticate against a DB or LDAP to get round the nasty file read/write lock issue.
(In reply to comment #3) > The idea of a dummy module is ideal, otherwise the server is open to abuse for > unwanted connections. Of course, the dummy module can do the same special authentication for first-time clients that you would have had rsync do. I left the first-time authentication out of my demo because I wasn't sure how you wanted it done. > A wishlist is to have rsync authenticate against a DB or LDAP to get round the > nasty file read/write lock issue. It would make more sense for rsync daemons to support PAM. Then the administrator could configure the PAM service to use LDAP or whatever.
Automatic module creation should be done outside of rsync unless a compelling reason to do it in rsync arises.