StatusNet Subscription Hacking

Some time back, @sazius changed his StatusNet instance from 'SSL always' to 'SSL sometimes'.

My hunch was right. I had problems subscribing to @jezra, switched from always SSL to sometimes. Worked fine. Hope doesn't break smth else:)

sazius (sazius)'s status on Friday, 30-Mar-12 18:53:19 UTC - status.saz.im

This change caused me to not receive any notices from him aside from direct @-replies. I tried to fix this a few different times without success. Until today. I should also note that I tried to resub (via the browser) to him however, every different way I tried, I would just get a "Could not set up the remote subscription" error message. I also tried running the "two-step" but, it would only return an error as well. Well, crap. Off to the command line then...

Before proceeding with this post though, I will mention that it's a real brain dump in the realm of $ cat /home/jpope/brain > /home/jpope/blog and may not make much sense. I will also say that it'll make more sense for those used to the internals of StatusNet. Anyway, on with the brain dump...

Wow, I think this blog post I'm writing may be a confusing mess at the moment... #braindump

Jeremy Pope (jpope)'s status on Saturday, 13-Oct-12 14:12:47 CDT - micro.jpope.org

To start debugging this, I headed to my StatusNet logs and poked around for a little bit. I was seeing that my instance was PuSHing just fine to sazius's instance aside from doing it twice. I wasn't too worried about that at the moment but did notice that any @-replies from him was showing up in my logs, just not populating in my timeline.

So, off to the database, Batman. First, I started poking around some of the profile tables such as profile and ostatus_profile. For whatever reason, I found that there were two entries for his profile in the ostatus_profile table, one with http://status.saz.im/api/statuses/user_timeline/1.atom as the feeduri and one with https://status.saz.im/api/statuses/user_timeline/1.atom (note the http and https). I noted the profile_id for each of these entries and found the corresponding entry in the profile table. I also looked in the subscription table to see what profile id's were subscribed to who. The subscription table has a subscriber and subscribed field. I found one of the profile id's in the subscriber column (with my id in the subscribed) which represented his subscription to me. I couldn't find an entry going the other way, which made since as I wasn't currently subbed to him. I also looked in the feedsub table and found the entry there regarding his instance. The sub_state field was sitting at "subscribe" which meant that I attempted to sub but it didn't complete the action. Again, makes sense with the subscribe fail from earlier. So, I forced it.

In the feedsub table, I changed the "subscribe" to "active". And in the subscription table, I copied a record where I was subscribed to someone and modified it for the "good" sazius profile id. I determined that the profile id where he was subbed to me to be the "good" one, which was id number 62. The subscribed field was set to 62 and the uri field was set to:

tag:micro.jpope.org,2011-11-15:follow:1:62:2011-11-15T14:36:33-06:00

The section ...follow:1:62:... shows that profile 1 (me) is following profile 62 (sazius). And the last step I did here was to delete the "bad" profile id from the ostatus_profile table since I figured that it was going to affect anyone's subscriptions.

Result? Still broke. At least at this point. These changes may have helped in the long run though so it wasn't necessarily wasted time.

Since I felt that things in the db were looking ok, I headed to the ./plugins/OStatus/scripts directory and started playing with some of those scripts. Long story short, it seems that the update-profile-data.php and update-profile.php scripts did the trick. I have previously tried these scripts and they would fail to update properly or I would see some other errors. Possibly my db hacking above helped this time because both of these scripts ran successfully today.

php update-profile.php https://status.saz.im/user/1

php update-profile-data.php https://status.saz.im/user/1

And after a few moments of running this, my instance received it's first notice from sazius in months (ok, it's been seven months, I guess I wasn't in too much of a hurry but, I was hoping that it would resolve itself as quite a few StatusNet issue seem to do). After spending the morning digging through logs and such, it seems that the solution for me was quite simple.

Can't say that any of this will help any bad subscriptions you may have on your StatusNet instance but, it helped me today.

EDIT 2012.10.14: Some people have had to run the update-profile scripts against the non-SSL address ( http://status.saz.im/user/1 ) as opposed to the https. Also, some have needed to resub after running the scripts in order for it all to get working as well.


Have a response to this post? Please use this link.