Re: [gentoo-dev] Private SVN repository for live-ebuild

2011-01-30 Thread Natanael Olaiz
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.





Re: [gentoo-dev] Private SVN repository for live-ebuild

2011-01-28 Thread Donnie Berkholz
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


pgpw94VbQQOSR.pgp
Description: PGP signature


Re: [gentoo-dev] Private SVN repository for live-ebuild

2011-01-28 Thread Maciej Mrozowski
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


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Private SVN repository for live-ebuild

2011-01-28 Thread Zac Medico
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



[gentoo-dev] Private SVN repository for live-ebuild

2011-01-27 Thread Natanael Olaiz
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




Re: [gentoo-dev] Private SVN repository for live-ebuild

2011-01-27 Thread Matthew Summers
On Thu, Jan 27, 2011 at 9:16 AM, Natanael Olaiz nol...@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


Re: [gentoo-dev] Private SVN repository for live-ebuild

2011-01-27 Thread Zac Medico
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



Re: [gentoo-dev] Private SVN repository for live-ebuild

2011-01-27 Thread Matthew Summers
On Thu, Jan 27, 2011 at 11:24 AM, Zac Medico zmed...@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


Re: [gentoo-dev] Private SVN repository for live-ebuild

2011-01-27 Thread Zac Medico
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