Re: [gentoo-dev] Re: Remaining PMS todo list etc
On Thu, 20 Mar 2008 18:02:31 -0600 Ryan Hill [EMAIL PROTECTED] wrote: How about just checking EUID == 0 in src_test and skip the tests (with a ewarn message) if it doesn't match your needs? I thought I remembered someone raising a stink about checking permissions being a race condition because the condition can change between the checking and performing the action. Maybe that was only about write permissions... That's in cases like if [[ -w foo ]] ; then blah foo ; fi . Checking a variable that's constant for the phase is not racy. If checking EUID is an acceptable method, it should be relatively simple to write an eclass to handle the common cases and have ebuilds use that instead of checking $FEATURES (which i do think is a bug). Does it really need an eclass for something so simple? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Trying to create nessus-bin-3.2.0 ebuild
Hello!
I'm trying to create nessus-bin-3.2.0 ebuild.
I've downloaded Nessus-3.2.0-suse10.0.i586.rpm, checked its md5 sum, and
I've done just a `cp nessus-bin-3.0.5.ebuild nessus-bin-3.2.0.ebuild`.
But even scr_unpack() fails:
Unpacking Nessus-3.2.0-suse10.0.i586.rpm to
/tmp/portage/net-analyzer/nessus-bin-3.2.0/work
!!! ERROR: net-analyzer/nessus-bin-3.2.0 failed.
Call stack:
ebuild.sh, line 1638: Called dyn_unpack
ebuild.sh, line 763: Called qa_call 'src_unpack'
ebuild.sh, line 44: Called src_unpack
ebuild.sh, line 1328: Called rpm_src_unpack
rpm.eclass, line 72: Called die
!!! failure unpacking Nessus-3.2.0-suse10.0.i586.rpm
!!! If you need support, post the topmost build error, and the call stack if
relevant.
!!! A complete build log is located at '/tmp/portage/net-analyzer/nessus-
bin-3.2.0/temp/build.log'.
I've looked into rpm.eclass, and found that problem is in
rpm_unpack() {
.
rpmoff=`rpmoffset ${rpmfile}`
[ -z ${rpmoff} ] return 1
$ rpmoffset /path/to/Nessus-3.2.0-suse10.0.i586.rpm
$ echo $?
1
$ rpm2targz /usr/portage/distfiles/Nessus-3.2.0-suse10.0.i586.rpm
/usr/portage/distfiles/Nessus-3.2.0-suse10.0.i586.rpm - no magic
compression identifier found - skipping file
$ emerge -pv rpm2targz
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] app-arch/rpm2targz-9.0-r6 0 kB
How can I fix this?
Thanks.
--
Vladimir Rusinov
Voronezh, Russia
UNIX Admin @ Murano Software
Re: [gentoo-dev] Testing to see if services have crashed on hardened
On 21-03-2008 10:20:45 +, Roy Marples wrote: Hi List. I've just removed the code to check for euid when running services and instead relying on permissions of the service state dir and testing errno. This is a good thing, but it does have one side effect. OpenRC can track daemons by how they were started. So every time you run rc-status it tests each reported service to ensure all daemons are up. This also works fine unprivileged on normal boxes - except for hardened where users can only see their own processes. Assuming you would use libkvm, on Darwin this means as unprivileged user (not using suid) you can't see any processes at all. This isn't really an easy answer, as we could have installed OpenRC in a prefix where this wouldn't apply, but we don't know that either. Ideas anyone? Is there a way to just have some fallback method which is less functional, but just uses some pid file with a lock or something? -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Testing to see if services have crashed on hardened
On Fri, 2008-03-21 at 10:20 +, Roy Marples wrote:
Hi List.
I've just removed the code to check for euid when running services and
instead
relying on permissions of the service state dir and testing errno. This is a
good thing, but it does have one side effect.
OpenRC can track daemons by how they were started. So every time you run
rc-status it tests each reported service to ensure all daemons are up. This
also works fine unprivileged on normal boxes - except for hardened where
users can only see their own processes.
This isn't really an easy answer, as we could have installed OpenRC in a
prefix where this wouldn't apply, but we don't know that either.
Ideas anyone?
err... run rc-status as root?
I mean if you are not supposed to see if a process is running or not as
normal user, then hardned is doin it's job when does not allow rc-status
to show this info to the unprivileged user.
if (!HARDENED || (HARDENED euid=0) {
/* show if process is running or not */
}
Thanks
Roy
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Remaining PMS todo list etc
Hi,
Ciaran McCreesh [EMAIL PROTECTED]:
On Thu, 20 Mar 2008 08:52:40 +0100
Christian Faulhammer [EMAIL PROTECTED] wrote:
if has userpriv ${FEATURES} ! has usersandbox ${FEATURES};then
make check-local || die test suite failed
else
ewarn Activate FEATURES=userpriv and deactivate \
FEATURES=usersandbox to run testsuite.
fi
^ That's mlocate, mysql also tests for FEATURES.
Yeah, and that's a strong case for why we don't want FEATURES used in
ebuilds -- the ebuild is copying package manager internal logic that
has changed in the past and may well change in the future.
Great, I accept that it is wrong, but can you tell me how to actually
rewrite it? Test for capabilities (read/write) on files or is there a
sane way to tell?
V-Li
--
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
URL:http://www.faulhammer.org/
signature.asc
Description: PGP signature
[gentoo-dev] Re: bzr.eclass into Portage
Hi, Jorge Manuel B. S. Vicetto [EMAIL PROTECTED]: you can check the current version used in desktop-effects at http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.eclass;hb=master Yes, I did not find xeffects, but desktop-effects I now know. With the help of Ingmar we did some cleanup and added support for eclass-manpages at http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.eclass;hb=bzr. I'll be moving the updated eclass to the master branch, testing and asking users to try it out during this weekend. This eclass is used in the overlay for the live avant-window-navigator ebuilds, so it's probably not as used/tested as the remaining packages. It has provided us the support we needed for awn, but you might need additional features or to review existing ones. Please test the updated eclass on your overlay, feel free to maintain it and, when you think its ready, add it to the tree. When you do so, I'll remove it from our overlay and we'll use the eclass on the tree. We have a prior version for some time now in the Emacs overlay for two live ebuilds...so we go and merge your changed (ulm already did), test it and report any problems. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: Re: Re: RFC: New build types
Petteri Räty wrote: Steve Long kirjoitti: I don't see how it would wreak more havoc than a novice using, eg ANT from Java which s/he is comfortable with, and then further having to learn BASH peculiarities when things don't fit with the eclass. But yeah, the fun is what attracts me to the idea more than anything. Java needs to be compiled and ant is meant to be started from the command line. Of course you can invoke the main method from Java but what's the point? Developers have to be able to review ebuilds and having all those different languages would make the job harder and I don't really see benefits. If you need something bit more complex done in an ebuild, you can always use something like inline python. Yeah, sorry I haven't used Java seriously since 1.1 (apart from some MIDP stuff) so haven't used ANT. I'm thinking more in terms of how Java was touted as network code, similar to tcl (which is one scripted setup I would be interested in.) So where you have a VM already instantiated, along with whatever SecurityManager and so on, you have a framework for user, shared or system installs, according to privilege level, with dependency resolution handled by the package manager. (The dependencies don't have to be confined to what the language knows about.) You're right though, that's not of so much interest for stuff where you already have ebuilds with associated shell infra, which you're used to maintaining. Thanks, igli. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Testing to see if services have crashed on hardened
On Friday 21 March 2008 10:37:11 Fabian Groffen wrote: Assuming you would use libkvm, on Darwin this means as unprivileged user (not using suid) you can't see any processes at all. That's different from FreeBSD and NetBSD then. This isn't really an easy answer, as we could have installed OpenRC in a prefix where this wouldn't apply, but we don't know that either. Ideas anyone? Is there a way to just have some fallback method which is less functional, but just uses some pid file with a lock or something? Not all services use pidfiles. Also, some services re-fork and re-write their pidfiles and I'm not sure the lock would carry across in that instance. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Testing to see if services have crashed on hardened
On Friday 21 March 2008 10:44:12 Natanael Copa wrote:
err... run rc-status as root?
I mean if you are not supposed to see if a process is running or not as
normal user, then hardned is doin it's job when does not allow rc-status
to show this info to the unprivileged user.
if (!HARDENED || (HARDENED euid=0) {
/* show if process is running or not */
}
Ideally I'd like a runtime catch rather than a define for this though, but
that's probably the best idea thus far.
Thanks
Roy
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Testing to see if services have crashed on hardened
On Fri, 2008-03-21 at 12:08 +, Roy Marples wrote:
On Friday 21 March 2008 10:44:12 Natanael Copa wrote:
err... run rc-status as root?
I mean if you are not supposed to see if a process is running or not as
normal user, then hardned is doin it's job when does not allow rc-status
to show this info to the unprivileged user.
if (!HARDENED || (HARDENED euid=0) {
/* show if process is running or not */
}
Ideally I'd like a runtime catch rather than a define for this though, but
that's probably the best idea thus far.
/* pid 1 is most likely owned by root */
hardened = pid_is_running(1);
if (!hardened || (hardened euid==0) {
-nc
Thanks
Thanks for working on openrc.
Roy
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Re: Re: RFC: New build types
Brian Harring wrote:
On Thu, Mar 20, 2008 at 06:51:13AM +, Steve Long wrote:
I don't have figures, but my understanding is that one of the major
factors in pkgcore's speed (which *is* impressive, even if the UI isn't
quite there yet) is that it doesn't reload bash for every phase. (The
whole ebuild daemon or ebd thing.)
From a speed standpoint, EBD is only relevant if we're talking about
metadata regeneration-
http://gentooexperimental.org/~ferringb/blog/archives/2005-03.html#e2005-03-05T16_59_39.txt
Ah OK; thanks, very interesting post.
Generally speaking, if you're sourcing to get metadata (regardless of
the underlying format), you're already screwed- cache exists for a
reason and is massively faster to rely on. Pkgcore's speed comes
about from careful design + a massive amount of JIT, EBD is faster
then the alternatives but that's *only* relevant for metadata
regeneration.
Would the metadata regen be quicker if the relevant file were in python
rather than bash?
Finally, bear in mind we're talking about build phase here- even if
the pkg is just a straight unpack/copy, the bottleneck there isn't
going to be the bash bits for setting up the env, it's going to be the
unpack, copy, multiple QA checks that do repeated find's across ${D},
multiple file invocations for same file, etc. Seriously- profile a
merge sometime, even on non-compilations the large time slices are
never bash.
Understood; thanks for discussing.
I was under the impression that implicit in the design of portage/pkgcore,
was that build scripts wouldn't necessarily be in bash, and that ebuild was
simply the bash format. Other formats in scripting languages seemed a
no-brainer; sorry if it was off-base.
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Testing to see if services have crashed on hardened
On Friday 21 March 2008 12:39:48 Natanael Copa wrote:
/* pid 1 is most likely owned by root */
hardened = pid_is_running(1);
if (!hardened || (hardened euid==0) {
OK, we'll go with that for the time being.
Thanks
Roy
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Remaining PMS todo list etc
Ciaran McCreesh wrote: On Thu, 20 Mar 2008 18:02:31 -0600 Ryan Hill [EMAIL PROTECTED] wrote: How about just checking EUID == 0 in src_test and skip the tests (with a ewarn message) if it doesn't match your needs? I thought I remembered someone raising a stink about checking permissions being a race condition because the condition can change between the checking and performing the action. Maybe that was only about write permissions... That's in cases like if [[ -w foo ]] ; then blah foo ; fi . Checking a variable that's constant for the phase is not racy. If checking EUID is an acceptable method, it should be relatively simple to write an eclass to handle the common cases and have ebuilds use that instead of checking $FEATURES (which i do think is a bug). Does it really need an eclass for something so simple? Considering the number of ebuilds that check FEATURES, disable tests altogether, or just do nothing and fail for half our users, against the number that do it correctly... apparently yeah. The simpler we make it to use, the more people will use it. On the other hand, it might be better to just document the common cases along with some example code in the Dev Guide. I'd be happy with doing that. -- fonts, gcc-porting, by design, by neglect mips, treecleaner,for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-dev-announce] New developer: Thomas Sachau (tommy)
On Thu, Mar 20, 2008 at 7:07 PM, Petteri Räty [EMAIL PROTECTED] wrote: Part of the ever growing German conspiracy, we have Thomas (tommy) Sachau. He will be joining us to help with the pile of broken ebuilds that some people call the Sunrise overlay. He has previously contributed to the Freenet project. On his free time he likes listening to music and attending concerts. On IRC you can find him as Tommy[D]. Welcome Tommy! -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
