How would you wipe a user's roster completely?

[Adam Nielsen]

Hi all,

I'm using mod_roster_command to automatically add new users to all
users' roster, and this is working very nicely.

However the problem is that now we have a large number of staff members
who no longer work here still on everyone's roster, and I'm not sure of
the best way to get rid of them.

mod_roster_command does have an unsubscribe command and I can
unregister users from the server, but the problem is I only have a list
of current staff - I don't know the usernames of the staff who should be
removed, so I don't know what usernames to pass to the 'unregister'
subcommand.

I thought a good way around this would be to just wipe everyone's
roster and repopulate it (which is fine because the users don't change
their roster and it gets updated every morning already) but I'm not
sure how to do this.

I tried deleting the roster .dat files, but when I run
mod_roster_command subscribe_both, the dat file does not get
recreated! If I delete the account .dat file then that does get
recreated when the account is re-registered so that part works fine.

Can anyone offer any pointers as to how you can wipe a user's roster
completely? It would be even better if it also removed the rosters of
users who no longer exist (as it would if all the .dat files in the
roster directory were deleted.)

Many thanks,
Adam.

[Waqas Hussain]

There are many ways to solve this problem.

Firstly, note that mod_roster_command operates on .dat files on disk. Deleting .dat files also affects the files on disk. If a user is logged in however,  their roster is loaded in memory, and editing the files on disk doesn't affect it until the user is completely logged out and logs back in again. If the user updates their roster before this, the in-memory version overwrites the version on disk. This may be why your deleting and re-subscribing isn't working. We are working on improving this situation in future Prosody versions.

Another reason could be that you are not using files, and have switched to SQL or other type of storage.

Is your goal to have all users in the roster of all other users? mod_groups may be a better solution than using mod_roster_command. If you prefer mod_roster_command for some reason, stop Prosody, delete roster .dat files, use mod_roster_command to repopulate rosters, start Prosody again.

--

Waqas Hussain

[Adam Nielsen]

> Firstly, note that mod_roster_command operates on .dat files on disk.
> Deleting .dat files also affects the files on disk. If a user is
> logged in however, their roster is loaded in memory, and editing the
> files on disk doesn't affect it until the user is completely logged
> out and logs back in again. If the user updates their roster before
> this, the in-memory version overwrites the version on disk.

This is fine - I plan to have it run in a nightly cron job, so if
anyone does this it will just leave their roster out of date for a day
or so.

> This may
> be why your deleting and re-subscribing isn't working. We are working
> on improving this situation in future Prosody versions.

I don't think this is the problem. I have gone offline with an
account, deleted the .dat, then tried to run mod_roster_command and
the .dat file for that (currently offline) user is not recreated. When
I go online again the roster is empty.

> Another reason could be that you are not using files, and have
> switched to SQL or other type of storage.

As above, deleting the .dat file makes the roster go empty so we're
definitely using files.

> Is your goal to have all users in the roster of all other users?
> mod_groups may be a better solution than using mod_roster_command. If
> you prefer mod_roster_command for some reason, stop Prosody, delete
> roster .dat files, use mod_roster_command to repopulate rosters,
> start Prosody again.

I can't recall the exact reason now but we were unable to use
mod_groups which is why Matthew was kind enough to create
mod_roster_command for us instead.

However further investigation has revealed something odd. It turns out
that no roster has been updated since last September - so
mod_roster_command is actually not modifying existing rosters either!

Any idea what would cause mod_roster_command to stop working? There
are no errors and the server logs don't show any problems. The
permissions on the roster folder are the same as on the accounts
folder, and "prosodyctl register" is able to create new account .dat
files, so there should be nothing preventing the prosody daemon from
creating the roster .dat files.

I'm not sure why this would have broken!

Thanks,
Adam.

[Waqas Hussain]

On Wed, Jun 11, 2014 at 7:14 PM, Adam Nielsen <adam.n...@uq.edu.au> wrote:

> Is your goal to have all users in the roster of all other users?
> mod_groups may be a better solution than using mod_roster_command. If
> you prefer mod_roster_command for some reason, stop Prosody, delete
> roster .dat files, use mod_roster_command to repopulate rosters,
> start Prosody again.

I can't recall the exact reason now but we were unable to use
mod_groups which is why Matthew was kind enough to create
mod_roster_command for us instead.

However further investigation has revealed something odd.  It turns out
that no roster has been updated since last September - so
mod_roster_command is actually not modifying existing rosters either!

Any idea what would cause mod_roster_command to stop working?  There
are no errors and the server logs don't show any problems.  The
permissions on the roster folder are the same as on the accounts
folder, and "prosodyctl register" is able to create new account .dat
files, so there should be nothing preventing the prosody daemon from
creating the roster .dat files.

I'm not sure why this would have broken! 

That's weird.

Have you updated or otherwise modified your Prosody install since September? Which Prosody version are you on?

I can't think of anything of the top of my head that could suddenly cause mod_roster_command to stop working. Can you test by creating two new users, subscribing them using mod_roster_command, and checking whether the .dat files were created?

--

Waqas Hussain

[Adam Nielsen]

> That's weird.
>
> Have you updated or otherwise modified your Prosody install since
> September? Which Prosody version are you on?

I have done a few upgrades from the Debian repository, but that's it.
I'm running Prosody 0.9.4 at the moment, which appears to be the latest
version available for this Debian system, which is still running the
previous stable version.

> I can't think of anything of the top of my head that could suddenly
> cause mod_roster_command to stop working. Can you test by creating
> two new users, subscribing them using mod_roster_command, and
> checking whether the .dat files were created?

Here is what happens:

$ cd /var/lib/prosody/my.domain
$ ls */test[12]*
ls: cannot access */test[12]*: No such file or directory
$ prosodyctl register test1 my.domain blah
$ prosodyctl register test2 my.domain blah
$ prosodyctl mod_roster_command subscribe_both te...@my.domain \
te...@my.domain
$ ls */test[12]*
-rw-r----- 1 prosody prosody 36 Jun 20 16:23 accounts/test1.dat
-rw-r----- 1 prosody prosody 36 Jun 20 16:24 accounts/test2.dat

It clearly creates the account files, but not the roster ones!

If, however, I modify my roster through a connected client, the server
does indeed write out an updated roster .dat file (successfully
creating it if the .dat doesn't exist.) So it looks like the problem is
in mod_roster_command rather than any other part of the system that
writes roster files.

Let me know if you have any other ideas or suggestions!

Many thanks,
Adam.

[Adam Nielsen]

> $ prosodyctl mod_roster_command subscribe_both

>
> It clearly creates the account files, but not the roster ones!

I just found I'm not the only one experiencing this problem:

https://code.google.com/p/prosody-modules/wiki/mod_roster_command

Looks like the module broke with Prosody 0.9.

I've done some investigating but I'm a bit stuck. In
core/usermanager.lua there is a function user_exists(). This is where
the problem occurs. If I force this function to return true then
everything works again, but for some reason this function is returning
false, indicating that user accounts do not exist when in fact they do.

The function calls hosts[host].users.user_exists() which is where the
incorrect value is coming from, but I cannot find where this function
is implemented. I thought perhaps it was in
modules/mod_auth_internal_plain.lua since in my main config file I have
the line 'authentication = "internal_plain"' however if I edit
modules/mod_auth_internal_plain.lua and change provider.user_exists()
to always return true then it makes no difference. This function is
not the one being called.

How can I work out which function is being called by
hosts[host].users.user_exists()?

Thanks,
Adam.