Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   Private SVN repository for live-ebuild (http://www.linux-archive.org/gentoo-development/481874-private-svn-repository-live-ebuild.html)

Natanael Olaiz 01-27-2011 02:16 PM

Private SVN repository for live-ebuild
 
Hi all,

I want to make a live-ebuild for a private subversion repository.
I see in the developers manual [1] that CVS have the vars ECVS_USER and
ECVS_PASS, but cannot found equivalent ones for SVN [2].

Anyone knows what would be the prefered way to do that? Is safe to
include the login in the ebuild? Can it have only read permissions to root?


And a similar case: a .tar.gz source package which is on a private web
URL. What is the best way to download it from the ebuild?


Thanks in advance,
Natanael.


[1]
http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html
[2]
http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/svn-sources/index.html

Matthew Summers 01-27-2011 04:05 PM

Private SVN repository for live-ebuild
 
On Thu, Jan 27, 2011 at 9:16 AM, Natanael Olaiz <nolaiz@gmail.com> wrote:

Hi all,



I want to make a live-ebuild for a private subversion repository.

I see in the developers manual [1] that CVS have the vars ECVS_USER and

ECVS_PASS, but cannot found equivalent ones for SVN [2].



Anyone knows what would be the prefered way to do that? Is safe to

include the login in the ebuild? Can it have only read permissions to root?





And a similar case: a .tar.gz source package which is on a private web

URL. What is the best way to download it from the ebuild?





Thanks in advance,

Natanael.





[1]

http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html

[2]

http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/svn-sources/index.html






Hi Natanael,
I just took a quick look at the eclass that determines the behavior you are interested in, and the short answer is yes that is supported via ESVN_USER and*ESVN_PASSWORD. I would strongly encourage you to read the actual eclass though, as it details other handy functionality too. That file is generally located in*/usr/portage/eclass/subversion.eclass

Now, as to whether to include the value*ESVN_PASSWORD in the ebuild, I would not do that. Personally, I would setup*svn+ssh and use an ssh key to access the repo. I do this with git using the git eclass. I am prompted for a password/key by portage in this case. To automate this using an ssh key, you can just use a passwordless key or setup ssh-agent. Also note, the key will be sought out first in /root/.ssh (I think it looks there first anyway).

Regarding your final question, I think that portage will ask you to enter the password if it tries to access something over HTTPS requiring authentication, but I am not 100% certain at the moment.

Regards,Matthew W. Summers

Zac Medico 01-27-2011 04:24 PM

Private SVN repository for live-ebuild
 
On 01/27/2011 09:05 AM, Matthew Summers wrote:
> Now, as to whether to include the value ESVN_PASSWORD in the ebuild, I would
> not do that. Personally, I would setup svn+ssh and use an ssh key to access
> the repo. I do this with git using the git eclass. I am prompted for a
> password/key by portage in this case. To automate this using an ssh key, you
> can just use a passwordless key or setup ssh-agent. Also note, the key will
> be sought out first in /root/.ssh (I think it looks there first anyway).

In this case, you could potentially have a problem if you have
FEATURES=userpriv enabled, since that would cause src_unpack to execute
as the "portage" user.

> Regarding your final question, I think that portage will ask you to enter
> the password if it tries to access something over HTTPS requiring
> authentication, but I am not 100% certain at the moment.

In this case, depending on the FETCHCOMMAND behavior, you could have a
problem with FEATURES=parallel-fetch since it launches fetches in the
background. So, if background fetch doesn't fail gracefully, you might
want to set FEATURES="-parallel-fetch" in /etc/make.conf.

Also, you could set PROPERTIES=interactive in the ebuild, in order
ensure that the fetcher is executed in the foreground.
--
Thanks
Zac

Matthew Summers 01-27-2011 06:08 PM

Private SVN repository for live-ebuild
 
On Thu, Jan 27, 2011 at 11:24 AM, Zac Medico <zmedico@gentoo.org> wrote:

On 01/27/2011 09:05 AM, Matthew Summers wrote:

> Now, as to whether to include the value ESVN_PASSWORD in the ebuild, I would

> not do that. Personally, I would setup svn+ssh and use an ssh key to access

> the repo. I do this with git using the git eclass. I am prompted for a

> password/key by portage in this case. To automate this using an ssh key, you

> can just use a passwordless key or setup ssh-agent. Also note, the key will

> be sought out first in /root/.ssh (I think it looks there first anyway).



In this case, you could potentially have a problem if you have

FEATURES=userpriv enabled, since that would cause src_unpack to execute

as the "portage" user.



> Regarding your final question, I think that portage will ask you to enter

> the password if it tries to access something over HTTPS requiring

> authentication, but I am not 100% certain at the moment.



In this case, depending on the FETCHCOMMAND behavior, you could have a

problem with FEATURES=parallel-fetch since it launches fetches in the

background. So, if background fetch doesn't fail gracefully, you might

want to set FEATURES="-parallel-fetch" in /etc/make.conf.



Also, you could set PROPERTIES=interactive in the ebuild, in order

ensure that the fetcher is executed in the foreground.

--

Thanks

Zac




These are excellent points Zac, thank you for illuminating this functionality.
One question though. Since the 'portage' user has its $home set by default to /var/tmp/portage how would you recommend handling the ssh key situation since that directory is somewhat special?

Thanks!
Matthew W. Summers

Zac Medico 01-27-2011 06:55 PM

Private SVN repository for live-ebuild
 
On 01/27/2011 11:08 AM, Matthew Summers wrote:
> One question though. Since the 'portage' user has its $home set by default
> to /var/tmp/portage how would you recommend handling the ssh key situation
> since that directory is somewhat special?

Well, I've never tried it, so I don't have any recommendation atm other
than to make sure FEATURES=userpriv is not enabled.

Moving forward, maybe it would make sense to have a notion of a
configurable "fetcher home" that package managers and live/vcs eclasses
would use for the HOME variable only when fetching. For example, the
user could configure this by setting a FETCHER_HOME variable.
--
Thanks,
Zac

Donnie Berkholz 01-28-2011 01:26 PM

Private SVN repository for live-ebuild
 
On 11:55 Thu 27 Jan , Zac Medico wrote:
> On 01/27/2011 11:08 AM, Matthew Summers wrote:
> > One question though. Since the 'portage' user has its $home set by default
> > to /var/tmp/portage how would you recommend handling the ssh key situation
> > since that directory is somewhat special?
>
> Well, I've never tried it, so I don't have any recommendation atm other
> than to make sure FEATURES=userpriv is not enabled.
>
> Moving forward, maybe it would make sense to have a notion of a
> configurable "fetcher home" that package managers and live/vcs eclasses
> would use for the HOME variable only when fetching. For example, the
> user could configure this by setting a FETCHER_HOME variable.

This might be useful in other scenarios besides fetching that just
haven't occurred to us yet. Perhaps we should treat the portage user as
a regular user with a regular home directory that can be configured as
desired, and flip in and out of that user on demand.

--
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com

Maciej Mrozowski 01-28-2011 04:40 PM

Private SVN repository for live-ebuild
 
On Friday 28 of January 2011 15:26:27 Donnie Berkholz wrote:
> On 11:55 Thu 27 Jan , Zac Medico wrote:
> > On 01/27/2011 11:08 AM, Matthew Summers wrote:
> > > One question though. Since the 'portage' user has its $home set by
> > > default to /var/tmp/portage how would you recommend handling the ssh
> > > key situation since that directory is somewhat special?
> >
> > Well, I've never tried it, so I don't have any recommendation atm other
> > than to make sure FEATURES=userpriv is not enabled.
> >
> > Moving forward, maybe it would make sense to have a notion of a
> > configurable "fetcher home" that package managers and live/vcs eclasses
> > would use for the HOME variable only when fetching. For example, the
> > user could configure this by setting a FETCHER_HOME variable.
>
> This might be useful in other scenarios besides fetching that just
> haven't occurred to us yet. Perhaps we should treat the portage user as
> a regular user with a regular home directory that can be configured as
> desired, and flip in and out of that user on demand.

Having SCM distfiles in user directory is not new 'market demand'.

Below there's subversion eclass enhancement request I opened some time ago
which I used to work around so far by denying emerge write access to
distfiles.
https://bugs.gentoo.org/show_bug.cgi?id=277976

--
regards
MM

Zac Medico 01-28-2011 07:35 PM

Private SVN repository for live-ebuild
 
On 01/28/2011 06:26 AM, Donnie Berkholz wrote:
> On 11:55 Thu 27 Jan , Zac Medico wrote:
>> On 01/27/2011 11:08 AM, Matthew Summers wrote:
>>> One question though. Since the 'portage' user has its $home set by default
>>> to /var/tmp/portage how would you recommend handling the ssh key situation
>>> since that directory is somewhat special?
>>
>> Well, I've never tried it, so I don't have any recommendation atm other
>> than to make sure FEATURES=userpriv is not enabled.
>>
>> Moving forward, maybe it would make sense to have a notion of a
>> configurable "fetcher home" that package managers and live/vcs eclasses
>> would use for the HOME variable only when fetching. For example, the
>> user could configure this by setting a FETCHER_HOME variable.
>
> This might be useful in other scenarios besides fetching that just
> haven't occurred to us yet. Perhaps we should treat the portage user as
> a regular user with a regular home directory that can be configured as
> desired, and flip in and out of that user on demand.

Well, the problem that I see with having a common $HOME for execution of
_all_ ebuilds is that it will be likely to accumulate all sorts of junk
from the various programs that are executed by ebuilds, and this can
lead to all sorts of bugs that may or may not be reproducible based on
the state of this directory on a given user's system.

Currently, portage always sets $HOME to a private temporary directory
which is a sibling of other private temporary directories such as
$WORKDIR, $T, and $D. This has the advantage of providing a clean slate
for each ebuild, ensuring reproducible results and no accumulation of junk.

This is why I suggested that we used a separate $HOME that is only for
fetching purposes, in order to minimize the risk of junk accumulation
and resulting problems with reproducibility.
--
Thanks,
Zac

Natanael Olaiz 01-31-2011 05:12 AM

Private SVN repository for live-ebuild
 
Hi,

El 01/27/11 18:24, Zac Medico escribió:
> On 01/27/2011 09:05 AM, Matthew Summers wrote:
>> Now, as to whether to include the value ESVN_PASSWORD in the ebuild, I would
>> not do that. Personally, I would setup svn+ssh and use an ssh key to access
>> the repo. I do this with git using the git eclass. I am prompted for a
>> password/key by portage in this case. To automate this using an ssh key, you
>> can just use a passwordless key or setup ssh-agent. Also note, the key will
>> be sought out first in /root/.ssh (I think it looks there first anyway).
> In this case, you could potentially have a problem if you have
> FEATURES=userpriv enabled, since that would cause src_unpack to execute
> as the "portage" user.
>
>> Regarding your final question, I think that portage will ask you to enter
>> the password if it tries to access something over HTTPS requiring
>> authentication, but I am not 100% certain at the moment.
> In this case, depending on the FETCHCOMMAND behavior, you could have a
> problem with FEATURES=parallel-fetch since it launches fetches in the
> background. So, if background fetch doesn't fail gracefully, you might
> want to set FEATURES="-parallel-fetch" in /etc/make.conf.
>
> Also, you could set PROPERTIES=interactive in the ebuild, in order
> ensure that the fetcher is executed in the foreground.

Matthew and Zac, thanks a lot for your very informative answers!


Best regards,
Natanael.


All times are GMT. The time now is 01:26 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.