-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Just following up on this - given everybody is talking about the Skype
outage (if they are able to talk to anybody that is), it seems like an
opportune time to mention that
running on
(RHEL|CentOS)+EPEL7 is just fine.
The reSIProcate 1.10.0~beta2 from Friday will probably be released
this week and I will make it available in both F23 and EPEL7. If
there is anything else we can do upstream to make this more
attractive/supportable for Fedora infrastructure then please let me know.
Regards,
Daniel
On 30/05/15 16:46, Daniel Pocock wrote:
On 22/05/15 16:21, Kevin Fenzi wrote:
> On Tue, 19 May 2015 13:45:39 +0200 Daniel Pocock
> <daniel(a)pocock.pro> wrote:
>>
>>
>> Hi all,
>>
>> At some point, it would be good to see
fedrtc.org migrate to
>> Fedora infrastructure and use the
fedoraproject.org domain
> Possibly. ;)
> Do you have any stats on usage since you announced it? I worry
> that we would get it all up and running and no one would use it.
> ;(
After the recent blog, about 12 people linked their FAS user IDs.
I don't have any other stats on how many minutes of calls they
make. It has only been promoted in one blog so far, I could
probably do more to promote it. Maybe if there was some
announcement email calling it an official trial more people may
sign up, even though there should not be any risk, people may even
be reluctant to use the OpenID thing knowing that it is not on
official infrastructure.
>> I'd be happy to submit the full request for resources[1] but I
>> just want to see if there is any initial comment on it. Here
>> is a list of what is involved:
>>
>> - it uses a PostgreSQL database schema[2]
>>
>> - it requires some DNS entries (SRV and NAPTR), examples[3]
>>
>> - it needs a TLS cert for
fedoraproject.org on the host(s)
>> where it runs
> Those are all easy. ;)
>> - it has static HTTP content and PHP that is currently hosted
>> with all but one problem[4] on a RHEL7 httpd. Content is in
>> Github[5], it could be presented as an RPM if necessary.
> I'm not too crazy about PHP. Would it be hard/possible to
> re-write things in something else? say flask?
I've been doing stuff with flask recently, I have no objections to
that. The main features of the code are the FAS OpenID
integration, running a PostgreSQL query and doing some HMAC stuff.
All of those things can be done in Python.
Do you have any example of how you implement flask applications
(or any other frameworks you support) for your hosting environment?
I have only ever used flask for trivial stuff running in my dev
environment, e.g.
https://github.com/dpocock/github-icalendar
https://github.com/dpocock/nagios-icalendar
> Is this a common codebase used by the other projects that run
> this?
It is basically the php-OpenID sample code with a PostgreSQL
INSERT after the user logs in.
We could probably find a Python OpenID sample, import psycopg2 and
get the same result.
>> - all packages are in EPEL7, except: cajun-json in EPEL6, in
>> testing for EPEL7 resiprocate in Fedora, builds from SRPM on
>> RHEL7
>>
>> - the SIP proxy is a single daemon, managed by systemctl. All
>> settings in a single file, /etc/repro/repro.config
>>
>> - the TURN server process is also a single daemon, managed by
>> systemctl. All settings in a single file,
>> /etc/reTurn/reTurnServer.config
>>
>> Just to clarify the scope of this: it is not a full telephony
>> service like Asterisk, just a SIP proxy and TURN server.
>> There is no persistent state information (as there would be
>> for voicemail, email service, etc) and no customized routing.
> Yeah, thats nice. ;)
> Some really dumb questions:
> * This does jabber/XMPP?
The TURN server can be used by XMPP clients to do voice and video
through NAT. Running a reTurn instance kills three birds with one
stone: SIP, XMPP and WebRTC
Currently,
fedrtc.org has a SIP proxy but no XMPP server.
Running an XMPP server would be an extra step. The Prosody
project leader, Matthew Wild (on CC), has been very supportive of
deployments for free software communities, e.g. he wrote this
module explicitly to help us use a common user database for SIP,
TURN and XMPP on
rtc.debian.org:
https://code.google.com/p/prosody-modules/wiki/mod_auth_ha1
and it is just as valid for a Fedora deployment. It is not hard
to get Prosody running.
There is one catch: if we run XMPP on
fedrtc.org, even
temporarily, then people will have to go through the pain of
migrating buddy lists to the
fedoraproject.org domain. Maybe it is
better to just run that on
fedoraproject.org from the beginning,
whenever you are happy to run it.
> * How about video/webrtc? with multiple people? or just person to
> person?
Yes, it supports video. As it is a SIP proxy, it doesn't actually
know about what is inside the streams or message bodies (voice,
video, text messaging). SIP proxies just provide a way to relay
things between endpoints. The SIP proxy also doesn't care about
things like codecs and transcoding, that makes the proxy easier to
administer and scale, but it means that the clients have to have
common capabilities.
Multi-party communication is also supported by the endpoints or by
running a conference server. E.g. somebody can run a private
Asterisk instance on their user(a)fedrtc.org address and other people
call them and join their personal conference. The SIP proxy
doesn't know or care, it just connects callers to the address they
specify.
In a later stage, Fedora could choose to run a dedicated
conference server, that would be something else to administer
though. My recommendation is just start with the lightweight SIP
proxy for some months and see if people volunteer to run services
like conferencing on their own infrastructure.
> * What are the common use cases you have seen people use it for?
Some Debian Developers have tried interviewing GSoC students using
WebRTC. It is important to show the students, from their very
first contact with our projects, that we don't depend on any
proprietary stuff like Skype or WhatsApp.
Another use case is testing the various SIP packages (GNOME
Empathy, Linphone, etc). If we want people to take these things
seriously we have to be able to show that we can run them in our
own communities, even if IRC and mailing lists are the preferred
means of communication.
Another use case is demonstrating federation. There was a demo at
a conference recently, a
debian.org user calling a
fedrtc.org user
with WebRTC.
>> Ongoing maintenance requirements: - TLS certificate renewals -
>> monitoring the ports - package updates from time to time
>>
>> It currently runs on a lab machine, I'd be happy to arrange
>> SSH access to the Fedora Infrastructure team to see exactly
>> what is involved and verify that it is manageable.
>>
>> Regards,
>>
>> Daniel
> Thanks for working on this. I find it definitely interesting...
> i just want to make sure we have enough use cases and people who
> would use it before we commit to running it.
Understood - I'm happy for it to continue on my server for now, but
if you email me your ssh key in a GPG signed email I'll let you log
in and look over it.
Regards,
Daniel
_______________________________________________ infrastructure
mailing list infrastructure(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJWAE5wAAoJEOm1uwJp1aqDi6gQALh6azmp9vL7rRHBB3nbJts8
P7SqQ5KpV/fZ76ZSNhXsrMTqNlFAYFp5na4g/O069+ajFciuqDf5bfBaeMMnnR3i
7jo5TGAmlXxwQWe6q5I9NMNbMkRLjbgit4TtXaX/N0+tFu3fPkfPIPiBbOY0G4ok
YEtmQtjf5KKMNfPaVzVPLY/r7gn+WId/pR3jQ9uYVhsMSC2KM/ne+iBhUZoQb5Ho
mIWQtEF9A+RsevqmWxfmj1nffTL2V304sFp44OaZa3LRfSCgwFeDfSqL6ZNKX1m2
vWA3R2gj4wm1L4kNh2Ymy/w5cpI/Bef4XVY2KVbmF18sKHMFE7vm+NcYwmWQ+cIm
gsiR1WiQkM528z3O9CnjYMxgXkUuqZxEeIu1aLMnWD4YiSE12vX9rTP/hQHIis2L
KPhYDEnl5dLK49lwSgGaApPJopBbkXsJwRJS+CSp4TNJlDRPM7UNiZWb3rYVUtgO
J94Lv2/AkjPTGie51hd8UZ4mGXs5sFIpLLZRDE+niGipxptPxKxUhsGUOGUHWq/M
Oo5g5DiwjLCwUtzjLHv3D3oOzYzdnesH/LsT8893Yc7NAqK0vpvaNAUcLW7w8VeB
HqAbXbHW51GZbLdYHpLFOn2VUVLwuG82BDhI9T6jkPXDnKFd7KBtTGuDp+UEw58v
4MzEpmSuEyv/+yP0hCGV
=fvPL
-----END PGP SIGNATURE-----
_______________________________________________
infrastructure mailing list
infrastructure(a)lists.fedoraproject.org