[gentoo-user] {OT} open-source: chat, tasks, resources, code

[gentoo-user] {OT} open-source: chat, tasks, resources, code

[Grant]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

When I need a new web-based software tool, I consider writing it myself and
if that isn't feasible I try to use something open-source and self-hosted.
 I need something for chat, task management, resource management, and code
management, all for groups.  I'm considering Campfire, Trello, Float, and
GitHub respectively, but I thought I'd check with you guys to see if any of
this is available in an open-source and self-hosted form, especially in
portage.

- Grant

[-- Attachment #2: Type: text/html, Size: 505 bytes --]

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Michael Orlitzky]

On 12/17/2012 02:26 AM, Grant wrote:
> When I need a new web-based software tool, I consider writing it myself
> and if that isn't feasible I try to use something open-source and
> self-hosted.  I need something for chat, task management, resource
> management, and code management, all for groups.  I'm considering
> Campfire, Trello, Float, and GitHub respectively, but I thought I'd
> check with you guys to see if any of this is available in an open-source
> and self-hosted form, especially in portage.
> 

Usual suggestions for github alternatives are,

  * Gitorious <http://gitorious.org/>

  * Gitolite <https://github.com/sitaramc/gitolite>

  * Gitlab <http://gitlabhq.com/>

None of them are very easy to set up.

If all you need to do is host git repositories, I suggest putting bare
repos on a server somewhere and having everyone push/pull over SSH. You
can use the bare-bones gitweb (comes with git in portage) to view the
repos from a web browser. You'll need a separate bug tracking mechanism
in that case.

For task management, we get away with a wiki (Mediawiki) and personal
TODO lists. It's fine for the people who actually use it. Getting people
to use it is the hard part. Your bug tracker can also double as a task list.

For chat, run an IRC or XMPP server.

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Michele Beltrame]

Hello!

>    * Gitolite <https://github.com/sitaramc/gitolite>

Gitolite is not that difficult to setup... you just need to follow the 
simple instructions... it works in most cases. ;)

Also, I recommend cgit as an alternative to gitweb.

Cheers,
Michele.

-- 
Michele Beltrame
http://www.italpro.net/ - mb@italpro.net
Skype: arthas77 - Twitter: _arthas

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Michael Orlitzky]

On 12/17/2012 12:05 PM, Michele Beltrame wrote:
> Hello!
> 
>>    * Gitolite <https://github.com/sitaramc/gitolite>
> 
> Gitolite is not that difficult to setup... you just need to follow the 
> simple instructions... it works in most cases. ;)
> 

It's not that it's hard to /get working/, it's that, to set it up
properly, you have to read through a mountain of documentation ten times
until you fully understand it and can deduce where they're being lazy
about security.

Then you have to adjust it all for your system, and document what you
learned and where you differ from the install docs.

This is hard in comparison to not doing it =)

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Grant]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

> > When I need a new web-based software tool, I consider writing it myself
> > and if that isn't feasible I try to use something open-source and
> > self-hosted.  I need something for chat, task management, resource
> > management, and code management, all for groups.  I'm considering
> > Campfire, Trello, Float, and GitHub respectively, but I thought I'd
> > check with you guys to see if any of this is available in an open-source
> > and self-hosted form, especially in portage.
> >
>
> Usual suggestions for github alternatives are,
>
>   * Gitorious <http://gitorious.org/>
>
>   * Gitolite <https://github.com/sitaramc/gitolite>
>
>   * Gitlab <http://gitlabhq.com/>
>
> None of them are very easy to set up.

I should stay away from those for now.

> If all you need to do is host git repositories, I suggest putting bare
> repos on a server somewhere and having everyone push/pull over SSH. You
> can use the bare-bones gitweb (comes with git in portage) to view the
> repos from a web browser. You'll need a separate bug tracking mechanism
> in that case.

I haven't used git before at all.  Is this pretty easy to set up?

> For task management, we get away with a wiki (Mediawiki) and personal
> TODO lists. It's fine for the people who actually use it. Getting people
> to use it is the hard part. Your bug tracker can also double as a task
list.
>
> For chat, run an IRC or XMPP server.

Has anyone used an XMPP client for communication/collaboration within a
company that they would recommend?

- Grant

[-- Attachment #2: Type: text/html, Size: 1947 bytes --]

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1903 bytes --]

On Dec 17, 2012 8:00 PM, "Grant" <emailgrant@gmail.com> wrote:
>
> > > When I need a new web-based software tool, I consider writing it
myself
> > > and if that isn't feasible I try to use something open-source and
> > > self-hosted.  I need something for chat, task management, resource
> > > management, and code management, all for groups.  I'm considering
> > > Campfire, Trello, Float, and GitHub respectively, but I thought I'd
> > > check with you guys to see if any of this is available in an
open-source
> > > and self-hosted form, especially in portage.
> > >
> >
> > Usual suggestions for github alternatives are,
> >
> >   * Gitorious <http://gitorious.org/>
> >
> >   * Gitolite <https://github.com/sitaramc/gitolite>
> >
> >   * Gitlab <http://gitlabhq.com/>
> >
> > None of them are very easy to set up.
>
> I should stay away from those for now.
>
>
> > If all you need to do is host git repositories, I suggest putting bare
> > repos on a server somewhere and having everyone push/pull over SSH. You
> > can use the bare-bones gitweb (comes with git in portage) to view the
> > repos from a web browser. You'll need a separate bug tracking mechanism
> > in that case.
>
> I haven't used git before at all.  Is this pretty easy to set up?

The most difficult piece of it is getting used to how the workflow differs
from something like cvs or svn.  I find the vim plugins "fugitive" and
"gitv", combined, make git very, very comfortable.

>
>
> > For task management, we get away with a wiki (Mediawiki) and personal
> > TODO lists. It's fine for the people who actually use it. Getting people
> > to use it is the hard part. Your bug tracker can also double as a task
list.
> >
> > For chat, run an IRC or XMPP server.
>
> Has anyone used an XMPP client for communication/collaboration within a
company that they would recommend?

I believe ejabberd is currently the best one available.

[-- Attachment #2: Type: text/html, Size: 2604 bytes --]

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Kevin Brandstatter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/17/2012 05:06 PM, Michael Mol wrote:

What ive done on one of my servers is created a git user account that
cant login interactively, or with a password. (nologin), whoever needs
access gives me their private key and i add it to the authorized_keys
for the git account.

This is obvoiusly very basic and you could create users for each
project etc, or use one of the many git server programs that will
allow to have more fine grained access control, Just depends on your
needs.

For chat, ive used campfire for the chicago marathon, its not much
more than a glorified irc system. IRC is perfectly fine if your on a
closed network. but i would keep it off the general internet.

resource and task management, i think eclipse and some ides have
integrated solutions, outside of that not really sure

- -Kevin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQz9CNAAoJENfP/Gsfo0VKoz4IAJ0GmU+RSPntz5nGOLqQO2W2
rWPfr+KdfE7lH6jQwBdztKtFkT8/00YrBgQJxlZJe+sQy5EP3QaCq8+Uscl86Bq8
d4TTCq3JyJr4eyo4Ycd8L06poediISt+++tTbWc324pofRCYWbHyyhe08Eux86PB
IXkemgCunwx1YIFEGPhPYGSf0kSCAeEvyNDCut+faYNvZbEolxdqFs/SBSXNvD4E
MHWzIConWqzlzHi5mn3l/B8yZmwEXQFIsgp3HgOhheIRafDYhR6wx8Kjca+Kbrz3
diteEpUIAS2+2g8+DigJz1vyhxSQyFZ4EjGlRGb4O1VzGONt7fVbFKar0/CV5hQ=
=J2VH
-----END PGP SIGNATURE-----

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Grant]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

> What ive done on one of my servers is created a git user account that
> cant login interactively, or with a password. (nologin), whoever needs
> access gives me their private key and i add it to the authorized_keys
> for the git account.
>
> This is obvoiusly very basic and you could create users for each
> project etc, or use one of the many git server programs that will
> allow to have more fine grained access control, Just depends on your
> needs.
>
> For chat, ive used campfire for the chicago marathon, its not much
> more than a glorified irc system. IRC is perfectly fine if your on a
> closed network. but i would keep it off the general internet.

An IRC server shouldn't listen on an internet-facing port?  Are there
security issues?

- Grant


> resource and task management, i think eclipse and some ides have
> integrated solutions, outside of that not really sure
>
> - -Kevin

[-- Attachment #2: Type: text/html, Size: 1057 bytes --]

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Kevin Brandstatter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/17/2012 06:33 PM, Grant wrote:
>> What ive done on one of my servers is created a git user account
>> that cant login interactively, or with a password. (nologin),
>> whoever needs access gives me their private key and i add it to
>> the authorized_keys for the git account.
>> 
>> This is obvoiusly very basic and you could create users for each 
>> project etc, or use one of the many git server programs that
>> will allow to have more fine grained access control, Just depends
>> on your needs.
>> 
>> For chat, ive used campfire for the chicago marathon, its not
>> much more than a glorified irc system. IRC is perfectly fine if
>> your on a closed network. but i would keep it off the general
>> internet.
> 
> An IRC server shouldn't listen on an internet-facing port?  Are
> there security issues?
> 
> - Grant
> 
> 
>> resource and task management, i think eclipse and some ides have 
>> integrated solutions, outside of that not really sure
>> 
>> - -Kevin
irc servers are notorious for botnets and the like and yes, are often
a prime target for remote exploitation. they can be secured like the
major systems, but it can be a bit more of a challenge

- -Kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQz9pZAAoJENfP/Gsfo0VKdjQH/1Dc0qWISZc8xcMFKgBGlTlR
ao8UHcyHIoJapWESVOq/VglGBOXwiW2gWfSeO5LD+td+7hwe+5ZgkIewrPij9Dx5
yXxXDae3Obcd2L5ROZ9AncctM26vpqwBzTyFm+MXuaJfdFXECLaA1aMNptIJF2fr
iLSUntTlOooa7Falv+RCDg0ROXbV9VBckYPb3nKC38gUJvebw71uc/soGC4bzM7l
+cZRx/hXbcvnqXk8mXBl+Ox2t/UJfJuXXh3brK0lg8ov9Adho/3yoyYOPAYYPFAA
JZVy1P7j1JfHBBl72QSOcGbK1NC9+vmaysm4dXQJV9pTL/uRp4va5F1Q0iMIbi8=
=szla
-----END PGP SIGNATURE-----

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Alan McKinnon]

On Mon, 17 Dec 2012 16:56:47 -0800
Grant <emailgrant@gmail.com> wrote:


> > For chat, run an IRC or XMPP server.
> 
> Has anyone used an XMPP client for communication/collaboration within
> a company that they would recommend?

Surely you meant server there, not client?

XMPP clients are a dime a dozen, take you pick: pidgin, kopete,
telepathy and a hots of others.

Servers are another story. All of them that you can lay your hands on
seem to suck big eggs big time. ejabberd is the only one I found
stable enough to actually stay up for sane amounts of time, and not
DEPEND on java.

But that info might be well out of date, I haven't looked at our
jabber server for ages. There's no need to - the techies all
gravitated by themselves over to GTalk and Skype, claiming that the
cloud services did everything they needed and more, and it was there,
and it worked. Our in-house jabber server - not so much.

Can't say I blame them. It's true.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Grant]

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

> > > For chat, run an IRC or XMPP server.
> >
> > Has anyone used an XMPP client for communication/collaboration within
> > a company that they would recommend?
>
> Surely you meant server there, not client?

I thought I meant client.  Does server functionality vary as far as what
shows up on the client end?  I imagined the client-facing functionality to
be the same amongst the various servers.

> XMPP clients are a dime a dozen, take you pick: pidgin, kopete,
> telepathy and a hots of others.
>
> Servers are another story. All of them that you can lay your hands on
> seem to suck big eggs big time. ejabberd is the only one I found
> stable enough to actually stay up for sane amounts of time, and not
> DEPEND on java.
>
> But that info might be well out of date, I haven't looked at our
> jabber server for ages. There's no need to - the techies all
> gravitated by themselves over to GTalk and Skype, claiming that the
> cloud services did everything they needed and more, and it was there,
> and it worked. Our in-house jabber server - not so much.
>
> Can't say I blame them. It's true.

Thanks Alan, this is just the kind of info I need.  It sounds like I would
be better off with a cloud solution for collaborative chat.

- Grant

[-- Attachment #2: Type: text/html, Size: 1468 bytes --]

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

Am Mon, 17 Dec 2012 18:04:46 -0800
schrieb Grant <emailgrant@gmail.com>:

[...]
> > XMPP clients are a dime a dozen, take you pick: pidgin, kopete,
> > telepathy and a hots of others.
> >
> > Servers are another story. All of them that you can lay your hands on
> > seem to suck big eggs big time. ejabberd is the only one I found
> > stable enough to actually stay up for sane amounts of time, and not
> > DEPEND on java.
> >
> > But that info might be well out of date, I haven't looked at our
> > jabber server for ages. There's no need to - the techies all
> > gravitated by themselves over to GTalk and Skype, claiming that the
> > cloud services did everything they needed and more, and it was there,
> > and it worked. Our in-house jabber server - not so much.
> >
> > Can't say I blame them. It's true.
> 
> Thanks Alan, this is just the kind of info I need.  It sounds like I would
> be better off with a cloud solution for collaborative chat.

Just out of curiosity: why couldn't you use a Jabber client with
Bonjour/Zeroconf support (all or most of them?) within the company (which is
what this is for IIUC)? With Zeroconf, the Jabber clients "find each other",
then you wouldn't need to bother with setting up a server.

Or is Zeroconf problematic? I know Pidgin can do Zeroconf on Windows, even if
you need to manually install a separate package for it to work.

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]

On Dec 18, 2012 6:33 AM, "Marc Joliet" <marcec@gmx.de> wrote:
>
> Am Mon, 17 Dec 2012 18:04:46 -0800
> schrieb Grant <emailgrant@gmail.com>:
>
> [...]
> > > XMPP clients are a dime a dozen, take you pick: pidgin, kopete,
> > > telepathy and a hots of others.
> > >
> > > Servers are another story. All of them that you can lay your hands on
> > > seem to suck big eggs big time. ejabberd is the only one I found
> > > stable enough to actually stay up for sane amounts of time, and not
> > > DEPEND on java.
> > >
> > > But that info might be well out of date, I haven't looked at our
> > > jabber server for ages. There's no need to - the techies all
> > > gravitated by themselves over to GTalk and Skype, claiming that the
> > > cloud services did everything they needed and more, and it was there,
> > > and it worked. Our in-house jabber server - not so much.
> > >
> > > Can't say I blame them. It's true.
> >
> > Thanks Alan, this is just the kind of info I need.  It sounds like I
would
> > be better off with a cloud solution for collaborative chat.
>
> Just out of curiosity: why couldn't you use a Jabber client with
> Bonjour/Zeroconf support (all or most of them?) within the company (which
is
> what this is for IIUC)? With Zeroconf, the Jabber clients "find each
other",
> then you wouldn't need to bother with setting up a server.
>
> Or is Zeroconf problematic? I know Pidgin can do Zeroconf on Windows,
even if
> you need to manually install a separate package for it to work.

That only works within the same mdns domain, which usually means being on
the same Ethernet segment.

>
> --
> Marc Joliet
> --
> "People who think they know everything really annoy those of us who know
we
> don't" - Bjarne Stroustrup

[-- Attachment #2: Type: text/html, Size: 2303 bytes --]

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Alan McKinnon]

On Tue, 18 Dec 2012 12:30:16 +0100
Marc Joliet <marcec@gmx.de> wrote:

> Am Mon, 17 Dec 2012 18:04:46 -0800
> schrieb Grant <emailgrant@gmail.com>:
> 
> [...]
> > > XMPP clients are a dime a dozen, take you pick: pidgin, kopete,
> > > telepathy and a hots of others.
> > >
> > > Servers are another story. All of them that you can lay your
> > > hands on seem to suck big eggs big time. ejabberd is the only one
> > > I found stable enough to actually stay up for sane amounts of
> > > time, and not DEPEND on java.
> > >
> > > But that info might be well out of date, I haven't looked at our
> > > jabber server for ages. There's no need to - the techies all
> > > gravitated by themselves over to GTalk and Skype, claiming that
> > > the cloud services did everything they needed and more, and it
> > > was there, and it worked. Our in-house jabber server - not so
> > > much.
> > >
> > > Can't say I blame them. It's true.
> > 
> > Thanks Alan, this is just the kind of info I need.  It sounds like
> > I would be better off with a cloud solution for collaborative chat.
> 
> Just out of curiosity: why couldn't you use a Jabber client with
> Bonjour/Zeroconf support (all or most of them?) within the company
> (which is what this is for IIUC)? With Zeroconf, the Jabber clients
> "find each other", then you wouldn't need to bother with setting up a
> server.
> 
> Or is Zeroconf problematic? I know Pidgin can do Zeroconf on Windows,
> even if you need to manually install a separate package for it to
> work.
> 

That doesn't really work when one fellow is at his desk in the office,
another at home on an ADSL connection and the third is a 3rd party dev
based in Los Angeles. That's quite common for me.

Zeroconf has it's uses, but it does have a rather narrow scope as to
where it can work. 

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 2919 bytes --]

Am Tue, 18 Dec 2012 14:50:51 +0200
schrieb Alan McKinnon <alan.mckinnon@gmail.com>:

> On Tue, 18 Dec 2012 12:30:16 +0100
> Marc Joliet <marcec@gmx.de> wrote:
> 
> > Am Mon, 17 Dec 2012 18:04:46 -0800
> > schrieb Grant <emailgrant@gmail.com>:
> > 
> > [...]
> > > > XMPP clients are a dime a dozen, take you pick: pidgin, kopete,
> > > > telepathy and a hots of others.
> > > >
> > > > Servers are another story. All of them that you can lay your
> > > > hands on seem to suck big eggs big time. ejabberd is the only one
> > > > I found stable enough to actually stay up for sane amounts of
> > > > time, and not DEPEND on java.
> > > >
> > > > But that info might be well out of date, I haven't looked at our
> > > > jabber server for ages. There's no need to - the techies all
> > > > gravitated by themselves over to GTalk and Skype, claiming that
> > > > the cloud services did everything they needed and more, and it
> > > > was there, and it worked. Our in-house jabber server - not so
> > > > much.
> > > >
> > > > Can't say I blame them. It's true.
> > > 
> > > Thanks Alan, this is just the kind of info I need.  It sounds like
> > > I would be better off with a cloud solution for collaborative chat.
> > 
> > Just out of curiosity: why couldn't you use a Jabber client with
> > Bonjour/Zeroconf support (all or most of them?) within the company
> > (which is what this is for IIUC)? With Zeroconf, the Jabber clients
> > "find each other", then you wouldn't need to bother with setting up a
> > server.
> > 
> > Or is Zeroconf problematic? I know Pidgin can do Zeroconf on Windows,
> > even if you need to manually install a separate package for it to
> > work.
> > 
> 
> That doesn't really work when one fellow is at his desk in the office,
> another at home on an ADSL connection and the third is a 3rd party dev
> based in Los Angeles. That's quite common for me.
> 
> Zeroconf has it's uses, but it does have a rather narrow scope as to
> where it can work. 

I understand that, I just thought that Grant was talking about a purely
internal chat solution (like my workplace has) - he did say "within a
company" (though admittedly in retrospect I realize that that doesn't
necessarily mean *physically* within the company).

Regardless, it isn't clear to me that Grant is talking about something that has
to be available from anywhere. While he is apparently gravitating towards a
"cloud solution" for chat, my understanding is that that is because then he
doesn't have to manage his own server. All of the other solutions mentioned
could be for internal *and* external use.

Anyway, I was just curious and thought that if this is purely for internal use
than Zeroconf might be a good server-less option for chat.

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Grant]

[-- Attachment #1: Type: text/plain, Size: 2821 bytes --]

> > > > > XMPP clients are a dime a dozen, take you pick: pidgin, kopete,
> > > > > telepathy and a hots of others.
> > > > >
> > > > > Servers are another story. All of them that you can lay your
> > > > > hands on seem to suck big eggs big time. ejabberd is the only one
> > > > > I found stable enough to actually stay up for sane amounts of
> > > > > time, and not DEPEND on java.
> > > > >
> > > > > But that info might be well out of date, I haven't looked at our
> > > > > jabber server for ages. There's no need to - the techies all
> > > > > gravitated by themselves over to GTalk and Skype, claiming that
> > > > > the cloud services did everything they needed and more, and it
> > > > > was there, and it worked. Our in-house jabber server - not so
> > > > > much.
> > > > >
> > > > > Can't say I blame them. It's true.
> > > >
> > > > Thanks Alan, this is just the kind of info I need.  It sounds like
> > > > I would be better off with a cloud solution for collaborative chat.
> > >
> > > Just out of curiosity: why couldn't you use a Jabber client with
> > > Bonjour/Zeroconf support (all or most of them?) within the company
> > > (which is what this is for IIUC)? With Zeroconf, the Jabber clients
> > > "find each other", then you wouldn't need to bother with setting up a
> > > server.
> > >
> > > Or is Zeroconf problematic? I know Pidgin can do Zeroconf on Windows,
> > > even if you need to manually install a separate package for it to
> > > work.
> > >
> >
> > That doesn't really work when one fellow is at his desk in the office,
> > another at home on an ADSL connection and the third is a 3rd party dev
> > based in Los Angeles. That's quite common for me.
> >
> > Zeroconf has it's uses, but it does have a rather narrow scope as to
> > where it can work.
>
> I understand that, I just thought that Grant was talking about a purely
> internal chat solution (like my workplace has) - he did say "within a
> company" (though admittedly in retrospect I realize that that doesn't
> necessarily mean *physically* within the company).
>
> Regardless, it isn't clear to me that Grant is talking about something
that has
> to be available from anywhere. While he is apparently gravitating towards
a
> "cloud solution" for chat, my understanding is that that is because then
he
> doesn't have to manage his own server. All of the other solutions
mentioned
> could be for internal *and* external use.
>
> Anyway, I was just curious and thought that if this is purely for
internal use
> than Zeroconf might be a good server-less option for chat.

I should have specified that the people in the organization are spread out
in different locations.

It sounds like it is difficult/dangerous to run an internet-facing IRC
server and ejabberd is unstable?

Besides chat, has anyone tried egroupware?

- Grant

[-- Attachment #2: Type: text/html, Size: 4016 bytes --]

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Michael Mol]

On Wed, Dec 19, 2012 at 3:14 PM, Grant <emailgrant@gmail.com> wrote:
>> > > > > XMPP clients are a dime a dozen, take you pick: pidgin, kopete,
>> > > > > telepathy and a hots of others.
>> > > > >
>> > > > > Servers are another story. All of them that you can lay your
>> > > > > hands on seem to suck big eggs big time. ejabberd is the only one
>> > > > > I found stable enough to actually stay up for sane amounts of
>> > > > > time, and not DEPEND on java.
>> > > > >
>> > > > > But that info might be well out of date, I haven't looked at our
>> > > > > jabber server for ages. There's no need to - the techies all
>> > > > > gravitated by themselves over to GTalk and Skype, claiming that
>> > > > > the cloud services did everything they needed and more, and it
>> > > > > was there, and it worked. Our in-house jabber server - not so
>> > > > > much.
>> > > > >
>> > > > > Can't say I blame them. It's true.
>> > > >
>> > > > Thanks Alan, this is just the kind of info I need.  It sounds like
>> > > > I would be better off with a cloud solution for collaborative chat.
>> > >
>> > > Just out of curiosity: why couldn't you use a Jabber client with
>> > > Bonjour/Zeroconf support (all or most of them?) within the company
>> > > (which is what this is for IIUC)? With Zeroconf, the Jabber clients
>> > > "find each other", then you wouldn't need to bother with setting up a
>> > > server.
>> > >
>> > > Or is Zeroconf problematic? I know Pidgin can do Zeroconf on Windows,
>> > > even if you need to manually install a separate package for it to
>> > > work.
>> > >
>> >
>> > That doesn't really work when one fellow is at his desk in the office,
>> > another at home on an ADSL connection and the third is a 3rd party dev
>> > based in Los Angeles. That's quite common for me.
>> >
>> > Zeroconf has it's uses, but it does have a rather narrow scope as to
>> > where it can work.
>>
>> I understand that, I just thought that Grant was talking about a purely
>> internal chat solution (like my workplace has) - he did say "within a
>> company" (though admittedly in retrospect I realize that that doesn't
>> necessarily mean *physically* within the company).
>>
>> Regardless, it isn't clear to me that Grant is talking about something
>> that has
>> to be available from anywhere. While he is apparently gravitating towards
>> a
>> "cloud solution" for chat, my understanding is that that is because then
>> he
>> doesn't have to manage his own server. All of the other solutions
>> mentioned
>> could be for internal *and* external use.
>>
>> Anyway, I was just curious and thought that if this is purely for internal
>> use
>> than Zeroconf might be a good server-less option for chat.
>
> I should have specified that the people in the organization are spread out
> in different locations.
>
> It sounds like it is difficult/dangerous to run an internet-facing IRC
> server and ejabberd is unstable?

This is what VPNs are for. I haven't really heard anything seriously
problematic about ejabberd outside of some folks dislike of adding
another language runtime.

Whatever you decide to run internally, you're going to need to become
knowledgeable in its administration. This is why a fair amount of
folks are outsourcing communications infrastructure. Few believe they
have the time to learn to manage the thing properly.

--
:wq

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Grant]

>> I should have specified that the people in the organization are spread out
>> in different locations.
>>
>> It sounds like it is difficult/dangerous to run an internet-facing IRC
>> server and ejabberd is unstable?
>
> This is what VPNs are for. I haven't really heard anything seriously
> problematic about ejabberd outside of some folks dislike of adding
> another language runtime.
>
> Whatever you decide to run internally, you're going to need to become
> knowledgeable in its administration. This is why a fair amount of
> folks are outsourcing communications infrastructure. Few believe they
> have the time to learn to manage the thing properly.

Is ejabberd difficult to run over the internet safely?

- Grant

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Alan McKinnon]

On Thu, 20 Dec 2012 13:02:46 -0800
Grant <emailgrant@gmail.com> wrote:

> >> I should have specified that the people in the organization are
> >> spread out in different locations.
> >>
> >> It sounds like it is difficult/dangerous to run an internet-facing
> >> IRC server and ejabberd is unstable?
> >
> > This is what VPNs are for. I haven't really heard anything seriously
> > problematic about ejabberd outside of some folks dislike of adding
> > another language runtime.
> >
> > Whatever you decide to run internally, you're going to need to
> > become knowledgeable in its administration. This is why a fair
> > amount of folks are outsourcing communications infrastructure. Few
> > believe they have the time to learn to manage the thing properly.
> 
> Is ejabberd difficult to run over the internet safely?

Not especially difficult. It's just another daemon that runs and does
things much like classic daemons do. It listens to one port and doesn't
do anything weird or funky.

To make it safe, you just follow regular guidelines about security,
firewalls etc. Your job is *much* easier if you intend to run a closed
server used only by users you create, which is what you intend if I
read it right.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Michael Mol]

On Thu, Dec 20, 2012 at 4:02 PM, Grant <emailgrant@gmail.com> wrote:
>>> I should have specified that the people in the organization are spread out
>>> in different locations.
>>>
>>> It sounds like it is difficult/dangerous to run an internet-facing IRC
>>> server and ejabberd is unstable?
>>
>> This is what VPNs are for. I haven't really heard anything seriously
>> problematic about ejabberd outside of some folks dislike of adding
>> another language runtime.
>>
>> Whatever you decide to run internally, you're going to need to become
>> knowledgeable in its administration. This is why a fair amount of
>> folks are outsourcing communications infrastructure. Few believe they
>> have the time to learn to manage the thing properly.
>
> Is ejabberd difficult to run over the internet safely?

I doubt it. But you'd want to give the docs a thorough reading to make
sure you have security questions locked down properly. Off the top of
my head...don't allow remote registrations (i.e. don't allow clients
to create accounts). Require SSL/TLS. Always make sure you're up on
the latest security patches.

Beyond that, you'd have to read docs. Which is what a lot of
self-described sysadmins can't be bothered to do.

--
:wq

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Grant]

>> Is ejabberd difficult to run over the internet safely?
>
> I doubt it. But you'd want to give the docs a thorough reading to make
> sure you have security questions locked down properly. Off the top of
> my head...don't allow remote registrations (i.e. don't allow clients
> to create accounts). Require SSL/TLS. Always make sure you're up on
> the latest security patches.
>
> Beyond that, you'd have to read docs. Which is what a lot of
> self-described sysadmins can't be bothered to do.

Fair enough.  It sounds like IRC is especially tricky with regard to
security but ejabberd isn't.

- Grant

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Michael Mol]

On Thu, Dec 20, 2012 at 4:32 PM, Grant <emailgrant@gmail.com> wrote:
>>> Is ejabberd difficult to run over the internet safely?
>>
>> I doubt it. But you'd want to give the docs a thorough reading to make
>> sure you have security questions locked down properly. Off the top of
>> my head...don't allow remote registrations (i.e. don't allow clients
>> to create accounts). Require SSL/TLS. Always make sure you're up on
>> the latest security patches.
>>
>> Beyond that, you'd have to read docs. Which is what a lot of
>> self-described sysadmins can't be bothered to do.
>
> Fair enough.  It sounds like IRC is especially tricky with regard to
> security but ejabberd isn't.

Dunno about that. You can set up IRC to be "authorized-users only" as
well. I imagine the only real difference for you would be the variety
of software clients your users have available to them.

(Also, as an aside, I've been at places with internal XMPP and with
internal IRC. I've found internal IRC to be far more flexible and
comfortable.)

--
:wq

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Michael Orlitzky]

On 12/17/2012 07:56 PM, Grant wrote:
> 
>> If all you need to do is host git repositories, I suggest putting bare
>> repos on a server somewhere and having everyone push/pull over SSH. You
>> can use the bare-bones gitweb (comes with git in portage) to view the
>> repos from a web browser. You'll need a separate bug tracking mechanism
>> in that case.
> 
> I haven't used git before at all.  Is this pretty easy to set up?
> 

If your users all have SSH access to some server, you don't have to do
anything at all. Git works by pushing and pulling from other
repositories. Those repos may reside on a friend's machine, or a server
somewhere; conceptually, it doesn't matter[1].

So, for example, I have a git repo for my reapply_default_acl project in
~/src. I can clone this somewhere else by doing,

  $ mkdir -p tmp/acl
  $ cd tmp/acl/
  $ git clone ~/src/reapply_default_acl
  Cloning into 'reapply_default_acl'...
  done.

that easy. To do it over SSH is identical. I can connect to my own
machine via SSH for another example:

  $ rm -rf reapply_default_acl
  $ $ git clone ssh://mjo@localhost:443/~/src/reapply_default_acl
  Cloning into 'reapply_default_acl'...
  Password:
  remote: Counting objects: 102, done.
  remote: Compressing objects: 100% (85/85), done.
  remote: Total 102 (delta 34), reused 3 (delta 0)
  Receiving objects: 100% (102/102), 33.86 KiB, done.
  Resolving deltas: 100% (34/34), done.

That's all that's involved. You give people "commit access" by allowing
them to write to the directory.


[1] This is a slight lie. If you're going to have a centralized repo
that you only push to, you'll want to do two things. First, create the
server repo with `git init --bare` so that you don't have an extra copy
of checked-out files lying around. Second, go into the 'hooks' folder of
the server repo and rename the post-update.sample file to post-update.

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Grant]

[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]

> >> If all you need to do is host git repositories, I suggest putting bare
> >> repos on a server somewhere and having everyone push/pull over SSH. You
> >> can use the bare-bones gitweb (comes with git in portage) to view the
> >> repos from a web browser. You'll need a separate bug tracking mechanism
> >> in that case.
> >
> > I haven't used git before at all.  Is this pretty easy to set up?
> >
>
> If your users all have SSH access to some server, you don't have to do
> anything at all. Git works by pushing and pulling from other
> repositories. Those repos may reside on a friend's machine, or a server
> somewhere; conceptually, it doesn't matter[1].
>
> So, for example, I have a git repo for my reapply_default_acl project in
> ~/src. I can clone this somewhere else by doing,
>
>   $ mkdir -p tmp/acl
>   $ cd tmp/acl/
>   $ git clone ~/src/reapply_default_acl
>   Cloning into 'reapply_default_acl'...
>   done.
>
> that easy. To do it over SSH is identical. I can connect to my own
> machine via SSH for another example:
>
>   $ rm -rf reapply_default_acl
>   $ $ git clone ssh://mjo@localhost:443/~/src/reapply_default_acl
>   Cloning into 'reapply_default_acl'...
>   Password:
>   remote: Counting objects: 102, done.
>   remote: Compressing objects: 100% (85/85), done.
>   remote: Total 102 (delta 34), reused 3 (delta 0)
>   Receiving objects: 100% (102/102), 33.86 KiB, done.
>   Resolving deltas: 100% (34/34), done.
>
> That's all that's involved. You give people "commit access" by allowing
> them to write to the directory.
>
>
> [1] This is a slight lie. If you're going to have a centralized repo
> that you only push to, you'll want to do two things. First, create the
> server repo with `git init --bare` so that you don't have an extra copy
> of checked-out files lying around. Second, go into the 'hooks' folder of
> the server repo and rename the post-update.sample file to post-update.

Thank you for taking the time to explain this.  You just sextupled my git
knowledge.  It does sound easy.  Would a basic layout like this plus gitweb
plus fugitive/gitv yield a git setup that wouldn't feel lacking for
collaboration amongst a few people?  It sounds like a bug tracker would be
a good addition.

- Grant

[-- Attachment #2: Type: text/html, Size: 2688 bytes --]

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Michael Orlitzky]

On 12/17/2012 08:59 PM, Grant wrote:
> 
> Thank you for taking the time to explain this.  You just sextupled my
> git knowledge.  It does sound easy.  Would a basic layout like this plus
> gitweb plus fugitive/gitv yield a git setup that wouldn't feel lacking
> for collaboration amongst a few people?  It sounds like a bug tracker
> would be a good addition.
> 

No problem. I can't speak for figutive/gitv, but as far as git itself is
concerned, it works great for us (a small team). None of the developers
actually use gitweb for anything, but it's nice to be able to show the
non-technical people "yes we are actually writing code sometimes."

A bug tracker would be a good addition. It not only provides a
collaborative todo list, but if public, will give your customers the
impression that their problems are being addressed.

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Kevin Brandstatter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/16/2012 11:26 PM, Grant wrote:
> When I need a new web-based software tool, I consider writing it myself and if that isn't feasible
I try to use something open-source and self-hosted. I need something for
chat, task management, resource management, and code management, all for
groups. I'm considering Campfire, Trello, Float, and GitHub
respectively, but I thought I'd check with you guys to see if any of
this is available in an open-source and self-hosted form, especially in
portage.
>
> - Grant
for hosted git theres gitosis and other web based git tools to host your
own private repository. For the rest im not too sure since I don't know
what your requirements are of the various bits.

- -Kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQz1GEAAoJEAwpfz/ORQZC85AH/0AGLLuwgJ7uHcFYcz3j1Y5l
UVympJzDjLo6nOAkdfE423cIbfMhb2xG7YUASy3s71sRdmkuZM4hKVZLspkGj2kZ
AQ1tcdYg67Lp0faQIOyc0V796P+WNtGJCrKNvvN7M3LIJm6AxjnpLHsryY05IQE6
Og0sVm/C+zqUOYfK9PWC2oFuM674pPVt1MbfjXJNdmL88TriW5Vv+QCeqprjVci1
TJ1RSAKfAsCOnc9XkKJZ7iq5RIRkXwrx7w+BZvg8nVd7p+77AAD1QsjgPKBh7Vju
VY6CiV5/6As6ljjRU+K3Wk6iGlhmZg82WKRB7eyX130Jee5bx+TipCIDiEy81u8=
=WWMz
-----END PGP SIGNATURE-----

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Grant]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

> > When I need a new web-based software tool, I consider writing it myself
and if that isn't feasible
> I try to use something open-source and self-hosted. I need something for
> chat, task management, resource management, and code management, all for
> groups. I'm considering Campfire, Trello, Float, and GitHub
> respectively, but I thought I'd check with you guys to see if any of
> this is available in an open-source and self-hosted form, especially in
> portage.
> >
> > - Grant
> for hosted git theres gitosis and other web based git tools to host your
> own private repository. For the rest im not too sure since I don't know
> what your requirements are of the various bits.
>
> - -Kevin

Neither do I. :)  I haven't really played with any of these types of
software before.  I just want to try out something oriented toward groups
or companies.

- Grant

[-- Attachment #2: Type: text/html, Size: 1024 bytes --]

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

[Ciprian Dorin Craciun]

On Mon, Dec 17, 2012 at 9:26 AM, Grant <emailgrant@gmail.com> wrote:
> When I need a new web-based software tool, I consider writing it myself and
> if that isn't feasible I try to use something open-source and self-hosted.
> I need something for chat, task management, resource management, and code
> management, all for groups.  I'm considering Campfire, Trello, Float, and
> GitHub respectively, but I thought I'd check with you guys to see if any of
> this is available in an open-source and self-hosted form, especially in
> portage.
>
> - Grant


    You should take a look at Fosil:
      http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki

    I haven't used it myself, but if you don't have strict preferences
for the versioning system you could use that, as it's very self
contained and easy to use.

    Ciprian.