|
|
|
|
|
|
| Author |
Message |
Goswin von Brederlow *nix forums Guru
Joined: 20 Feb 2005
Posts: 658
|
Posted: Sat Feb 19, 2005 7:20 pm Post subject:
Re: execturing libc
|
|
|
Andreas Rottmann <a.rottmann@gmx.at> writes:
| Quote: | Adrian von Bidder <avbidder@fortytwo.ch> writes:
On Wednesday 02 February 2005 06.35, Brian M. Carlson wrote:
I think you meant to ask, "Why would anyone want to execute the C
library?"
bmc@blackhole:~$ /lib/ld-linux.so.2 /lib/libc.so.6
Ok, this is off topic for this thread, but still, strangely:
avbidder@humphrey:~$ /lib/ld-2.3.2.so /lib/libc-2.3.2.so
Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed!
avbidder@humphrey:~$
(sarge/i386) on self-made 2.6.10 (Debian kernel source
The system works fine, no random failures or anything.
Same here (sarge/i386), kernel-image-2.6.8-2-k7
Rotty
|
That error is the reason why libc is no longer executable. It used to
be. The error seems to come and go on some archs it seem, amd64 is
currently working fine:
mrvn@frosties:~% /lib64/ld-linux-x86-64.so.2 /lib/libc-2.3.2.so
GNU C Library stable release version 2.3.2, by Roland McGrath et al.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.3.5 (Debian 1:3.3.5-6).
Compiled on a Linux 2.6.0-test7 system on 2005-01-12.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
NPTL 0.60 by Ulrich Drepper
BIND-8.2.3-T5B
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
Report bugs using the `glibcbug' script to <bugs@gnu.org>.
And exactly that info is the reason why one may want to execute libc.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Kevin Mark *nix forums Guru
Joined: 20 Feb 2005
Posts: 474
|
Posted: Sat Feb 19, 2005 7:20 pm Post subject:
Re: scripts to download porn in Debian?
|
|
|
On Wed, Feb 02, 2005 at 06:46:03PM -0700, Joel Aelwyn wrote:
| Quote: | On Wed, Feb 02, 2005 at 10:17:07PM +0100, Michelle Konzack wrote:
Am 2005-02-03 03:15:41, schrieb Sam Watkins:
1. People (including children) will get a nasty surprise when they
choose to download all the comics to see what is available.
My daughter had this problem several times...
*looks innocent*
Say, whatever happened to debian-junior? Isn't that the sub-project that
was for exactly this sort of concern?
--
Joel Aelwyn <fenton@debian.org> ,''`.
: :' :
`. `'
`-
|
Hi Joel,
there is also something being worked on called debtags. debian-junior is
conglomerate of packages to install but does not address the desire to
install stuff after 'debian-junior' is installed. This is where debtags
might come in. Maybe dpkg could be made debtags aware.
with an /etc/dpkg-debtags.conf with an option like
'DONTINSTALL=religious,adult,offensive'
just a thought.
-Kev
Ps. besides debian-junior, I and others thought of debian-muslim,
debian-christian,debian-german,debian-italian as other meta-packages to
address similar ideas.
--
counter.li.org #238656 -- goto counter.li.org and be counted!
(__)
(oo)
/------\/
/ | ||
* /\---/\
~~ ~~
...."Have you mooed today?"... |
|
| Back to top |
|
 |
Eric Lavarde *nix forums beginner
Joined: 19 Mar 2005
Posts: 13
|
Posted: Sat Feb 19, 2005 7:20 pm Post subject:
Re: Who could be able to help SW vendors to support Debian?
|
|
|
Hi,
as I understand myself as someone aware of the support problems of
software problems, I would like to point to 2 problems:
1. the Debian Kernel is a bit different from the kernel.org Kernel;
example: at work we used the Apani VPN client, which did work under all
kind of RedHat/SuSE kernel, but not under the Debian kernel, even though
there is some compiling done at installation time (i.e. not only
binary modules delivered).
2. as a software provider, you need to be able to reproduce the problem
of your customer to solve it (at least for non-obvious problems), so
that you can reproduce the problem in your environment, debug, correct
and test again. (I would also imagine there could be some legal
implications if you are officially supporting a certain setup, but
practically aren't able to support it properly; but we want to stay out
of the court ).
What is the consequence? you need a limited amount of possible
combinations, you need to have a stable system (in the sense: not
changing every three weeks) and you would greatly appreciate to be
informed of changes that might break your system before your customer
actually installs the patch/update/whatever.
Imagine a customer doing regularly an apt-get update & upgrade in order
to be sure to have the latest security fixes, and all of a sudden, your
expensive software stops to work, at all of your customers, almost at
once. You're out of business! Game over!
I'm exagerating a bit but that's what they want: no surprise, be able to
clearly define what is supported and what not (e.g. self compiled kernel
or not?!), have a chance to test before their own customers do.
This said, I don't have a clue who at Debian could provide this to them;
though I'd think Debian is probably best in these aspects than some
other platforms starting with W. Probably some training to understand
how Debian is working and structured might just be what they need.
Cheers, Eric
Tim Cutts wrote:
| Quote: | On Tue, Feb 01, 2005 at 07:37:27PM +0100, Christian Perrier wrote:
Would any people around have pointers which could be given to such
people?? Do we already have an entry point for such technical issues
as proprietary SW vendors needing technical information about the way
to support Debian??
The first thing I would do is to try to convince the vendor not to get
so hung up on supporting different distributions. If their product
depends tightly on kernel stuff, then they should base their support
matrix on kernel version, not on distribution.
Point them at Platform Computing as an example of how to do it with LSF.
They support Linux, and they don't give a stuff what distribution you're
running. They support certain kernels, and certain C libraries, and
other than that they don't care. And they're not too precise about
kernel version - on X86 you can run any 2.4 or 2.6 kernel, and any 2.1,
2.2 or 2.3 glibc. They're a little pickier on other architectures (they
don't support 2.6 on either Alpha or Itanium yet).
Tim
|
--
Gewalt ist die letzte Zuflucht der Inkompetenz.
Violence is the Last Resort of the Incompetent.
Gwalt jest ostatnem schronieniem niekompetencji.
La violence est le dernier refuge de l'incompetence.
~ Isaac Asimov
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Otto Wyss *nix forums beginner
Joined: 04 Mar 2005
Posts: 42
|
Posted: Sat Feb 19, 2005 7:20 pm Post subject:
Re: Debian mirror scripts
|
|
|
Goswin von Brederlow wrote:
| Quote: |
Why there isn't there already a rsync method for apt is probably a
mystery nobody ever will solve.
It is not wanted due to rsync causing excessive server load.
That is simply not true. This statement is repeated all the time but |
nobody ever was able to show hard figures.
Where rsync produces much load is during the phase when it collects all
the files for synchronisation and not during MD5 computation but this is
is only due to not well designed scripts. DpartialMirror doesn't impose
this phase since it only require single-file transfers and does the file
collecting phase on the client.
| Quote: | New versions. The size of the Packages files is comparatively tiny
compared to all the debs. Even the 1% saving for rsyncing debs is
hardly worth it due to the extra traffic for the checksums and the
server load it causes.
Sorry rsync reports the overall use, incl. checksums etc. |
Of course 1% saving doesn't make much sense so that's the main reason I
don't develop DpartialMirror further. Anyway the next time a
distribution concept is designed it will be based on a p2p solution.
| Quote: | zsync has the option of looking into gziped files and rsync them as if
they would be ungziped (while still just downloading chunks of the
gziped file). Its a bit more complex algorithm but works even better
than rsyncable files and rsync.
As long as zsync allows multi-file transfers it won't be better that rsync. |
O. Wyss
--
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wxguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Goswin von Brederlow *nix forums Guru
Joined: 20 Feb 2005
Posts: 658
|
Posted: Sat Feb 19, 2005 7:20 pm Post subject:
Re: Debian mirror scripts
|
|
|
Otto Wyss <otto.wyss@orpatec.ch> writes:
| Quote: | Goswin von Brederlow wrote:
Why there isn't there already a rsync method for apt is probably a
mystery nobody ever will solve.
It is not wanted due to rsync causing excessive server load.
That is simply not true. This statement is repeated all the time but
nobody ever was able to show hard figures.
|
Rsync by default uses ~3% of the file size in ram to store block
checksums. Consider a new kde-i18n release with its 200Mb file (for an
extrem case). 33 donloads waste 200MB ram, 330 download 2GB ram. When
do you thing the mirror will start swapping?
The ~3% are filled with the clients checksums first and then rsync
reads in the full file computing the adler32 checksum per byte and a
md4sum for each potential match.
Even though adler32 and md4 are very fast they are more load than just
sending out the file. And all that for just ~1% saving (without
rsyncable).
Worse is downloading multiple files (as you mention below) using
include and exclude patterns. Downloading 1000 files at once through
this takes somewhere around an hour just to build a file listing what
to get doing a complete find over the archive (wasting tons of I/O).
But downloading files seperately isn't that much better since then
every file opens a new connect and forks a new rsync on the
server. Starting a new full Debian-amd64 mirror with a 300ms ping
reply (that is what I get roughly) to the server would waste 75 hours
on waiting for the initial three-way handshake for a connect. And
another 50 hours for the round-robin sending the name of a file and
getting the data.
You can say all this is bad design in rsync and the solution is dead
simple (now): zsync.
| Quote: | Where rsync produces much load is during the phase when it collects all
the files for synchronisation and not during MD5 computation but this is
is only due to not well designed scripts. DpartialMirror doesn't impose
this phase since it only require single-file transfers and does the file
collecting phase on the client.
|
Depends on use and available client data.
| Quote: | New versions. The size of the Packages files is comparatively tiny
compared to all the debs. Even the 1% saving for rsyncing debs is
hardly worth it due to the extra traffic for the checksums and the
server load it causes.
Sorry rsync reports the overall use, incl. checksums etc.
|
What I ment is the extra outgoing traffic on the client side. For
example for dsl users sending the checksums might actualy slow things
more down than the 1% saving speeds things up.
| Quote: | Of course 1% saving doesn't make much sense so that's the main reason I
don't develop DpartialMirror further. Anyway the next time a
distribution concept is designed it will be based on a p2p solution.
zsync has the option of looking into gziped files and rsync them as if
they would be ungziped (while still just downloading chunks of the
gziped file). Its a bit more complex algorithm but works even better
than rsyncable files and rsync.
As long as zsync allows multi-file transfers it won't be better that rsync.
O. Wyss
|
zsync works via http. YOU have to know the filename to request, so no
large "find" like rsync does for multiple files, but through
keep-alive you can still do multiple files, even in parallel if you
like and code it, with a single connection.
Also note that zsync uses precomputed checksum files on the server
side and does the adler/md4 computations on the client. Thats why it
can use simple http/1.1. It's a win-win situation.
MfG
Goswin
PS: I think the sarge/sid rsync has improved the multiple file
download but that doesn't help woody.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Otto Wyss *nix forums beginner
Joined: 04 Mar 2005
Posts: 42
|
Posted: Sat Feb 19, 2005 7:20 pm Post subject:
Re: Debian mirror scripts
|
|
|
Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
| Quote: | Otto Wyss <otto.wyss@orpatec.ch> writes:
reply (that is what I get roughly) to the server would waste 75 hours
on waiting for the initial three-way handshake for a connect. And
another 50 hours for the round-robin sending the name of a file and
getting the data.
Did you messure this figures on a real Debian mirror or is it just what |
you think?
| Quote: | can use simple http/1.1. It's a win-win situation.
Perfect go ahead. Even if DpartialMirror isn't developed further I use |
it almost daily and are quite happy with it. And I guess this won't
change in the future.
O. Wyss
--
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wxguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Goswin von Brederlow *nix forums Guru
Joined: 20 Feb 2005
Posts: 658
|
Posted: Sat Feb 19, 2005 7:20 pm Post subject:
Re: Debian mirror scripts
|
|
|
otto.wyss@orpatec.ch (Otto Wyss) writes:
| Quote: | Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
Otto Wyss <otto.wyss@orpatec.ch> writes:
reply (that is what I get roughly) to the server would waste 75 hours
on waiting for the initial three-way handshake for a connect. And
another 50 hours for the round-robin sending the name of a file and
getting the data.
Did you messure this figures on a real Debian mirror or is it just what
you think?
|
That is pure mathematics.
An initial tcp three way handshake has to travel tree times the
distance between me and the server. That is 150ms * 3 just to connect
and then one roundtrip to get the data flowing. Even if the 3rd packet
of the handshake is combined with data (not sure if that happens just
now) you still have to wait for the reply. So 4 or 5 times 150ms times
the number of files (~600000).
But it's not only math, I've tested this (not with that many files
obviously) for debmirror using ftp (one data connect per file), http
(one connect per file), http (keep-alive), rsync (1 file per connect)
and rsync (100 files per connect).
Http with keep-alive wins.
| Quote: | can use simple http/1.1. It's a win-win situation.
Perfect go ahead. Even if DpartialMirror isn't developed further I use
it almost daily and are quite happy with it. And I guess this won't
change in the future.
|
If Debian starts shipping zsync checksum files in its mirror then
adapting to it should be trivial. Just add the Depends and replace the
rsync call with zsync. I just hope some ftp-master will.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Dirk Eddelbuettel *nix forums beginner
Joined: 20 Feb 2005
Posts: 30
|
Posted: Sat Feb 19, 2005 7:20 pm Post subject:
Re: [Pre-RFA] Intending to drop twenty-some packages
|
|
|
On 1 February 2005 at 14:46, Martin Michlmayr wrote:
| * Dirk Eddelbuettel <edd@debian.org> [2005-01-15 11:51]:
| > Please CC me on follow-ups to debian-devel, or email me directly if
| > you have any interest. I should follow up with RFA and O bug reports
| > over the next few weeks, but doing this informally first may be
| > simpler. Or maybe not.
|
| Did you keep track which packages have been spoken for and for which
| you still need to file RFA or O reports?
Sorry for not replying sooner, but I was under the weather with some sort of
flu and slept every non-work hour of the last two days.
| It seems at least tob is still outstanding. Gunnar Wolf seemed
| interested in some of the Perl packages but it's not quite clear to me
| which he'll actually adopt.
I'll quote from my original email and then summarise by paragraph:
On 15 January 2005 at 11:51, Dirk Eddelbuettel wrote:
| * the Octave complex
-- is now in the hands on the pkg-octave-devel group with octave2.1 as the
first (and only, so far) release. Thanks to Rafael for organising and
spear-heading this.
| * the gsl set:
-- is still mine though Bas Zoetekouw indicated that he would like to help. I
think I got Chris Steigies to agree to help too.
| * the Perl "spreadsheet" complex:
| - spreadsheet-writeexcel
| - spreadsheet-parseexcel (2 old open bugs, forwarded ages ago)
| - ole-storage-lite
| - dbd-excel (1 old open bug, forwarded)
-- was picked up en bloc by Gunnar Wolf, and already uploaded. Thanks, Gunnar!
| * other Perl packages:
| - dbd-odbc
| - finance-streamer
| - inline-octave [ related to Octave ]
| - math-numbercruncher
| - statistics-descriptive
Still up for grabs. Only dbd-octave had upstream releases lately -- and
should find a new home. The others are more esoteric. If it gets too bad I
can always orphan them later.
| * bc (with binary packages bc and dc)
-- picked up with an immediate upload by John Hasler. Thanks, John!
| * Miscellaneous
| - afio (2 open bugs, active upstream, pretty straightforward)
Picked up Erik Schanze who already uploaded a new package with several
patches that have since been blessed upstream. Thanks, Erik! (Eric is not a
full DD, if his AM reads this, my thumbs up!)
| - time (dead upstream)
-- picked up by Tollef (no new upload yet). Thanks, Tollef!
| - tob (fairly dead upstream despite CPR and a new upstream author recently)
-- still mine, but not that much work.
| - wajig (very active upstream, and well maintained upstream)
-- now officially Grahams, and I sponsor him -- Thanks, Graham!. Effectively,
that is what have done for the last one or two years anyway. (Graham is not a
full DD, if his AM reads this, my thumbs up!)
I still have approx 70 other packages ...
Dirk
--
Better to have an approximate answer to the right question than a precise
answer to the wrong question. -- John Tukey as quoted by John Chambers
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Brian May *nix forums Guru Wannabe
Joined: 27 Feb 2005
Posts: 109
|
Posted: Sat Feb 19, 2005 7:20 pm Post subject:
Re: scripts to download porn in Debian?
|
|
|
| Quote: | "Don" == Don Armstrong <don@debian.org> writes:
|
Don> 2. Should Debian publish content I disagree with which is
Don> DFSG free?
I am going to write a DFSG script that will download photos I have
taken from my website, and display them at random on the users screen.
There are no pornographic images and no nude images of humans. If nude
photos of dogs, cars, cats, birds or aircraft are a problem for
anyone, I can have them removed. There should no need for any
controversy.
Even better, I will just license the photos (currently 346Meg, but I
could make that several gigabytes) under a DFSG compatible license,
and include the whole set as a single Debian package in the next
stable release of Debian (or sarge+1).
Seriously, what has any of this got to do with Debian? I consider
Debian an operating system, not a method of transferring art, whether
digital images, digital video, writing, etc.
I really think we need to draw the line somewhere.
--
Brian May <bam@debian.org>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Don Armstrong *nix forums addict
Joined: 22 Feb 2005
Posts: 88
|
Posted: Sat Feb 19, 2005 7:20 pm Post subject:
Re: scripts to download porn in Debian?
|
|
|
On Fri, 04 Feb 2005, Brian May wrote:
| Quote: | "Don" == Don Armstrong <don@debian.org> writes:
Don> 2. Should Debian publish content I disagree with which is
Don> DFSG free?
I really think we need to draw the line somewhere.
|
We do draw the line somewhere currently:
1) Must be DFSG Free
2) Must have a maintainer willing to maintain it, and a Developer
willing to upload it.
ftp-masters (with occasional help of debian-legal) deal with
determining if #1 is satisfied.
Maintainers and Developers deal with determining if #2 is satisfied,
ideally by applying some sort of common sense to their decision. The
ITP anouncement on -devel helps to at least makes sure Developers are
aware of the issues surrounding their package.
If you're suggesting that we need to move where the line is drawn,
then by all means, propose some reasonable metric which can be applied
to all packages as an extension of these two (rather basic) rules. The
appropriate forum for that is -project (or possibly -policy).
Perhaps I'm naive, but I would hope that Developers are capable of
exercising their judgement on #2 with enough veracity to be all the
arbitration necessary.
Don Armstrong
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Wouter Verhelst *nix forums Guru
Joined: 04 Apr 2005
Posts: 558
|
Posted: Sat Feb 19, 2005 7:20 pm Post subject:
Re: execturing libc
|
|
|
On Thu, Feb 03, 2005 at 04:31:02PM +0100, Goswin von Brederlow wrote:
| Quote: | mrvn@frosties:~% /lib64/ld-linux-x86-64.so.2 /lib/libc-2.3.2.so
GNU C Library stable release version 2.3.2, by Roland McGrath et al.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.3.5 (Debian 1:3.3.5-6).
Compiled on a Linux 2.6.0-test7 system on 2005-01-12.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
NPTL 0.60 by Ulrich Drepper
BIND-8.2.3-T5B
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
Report bugs using the `glibcbug' script to <bugs@gnu.org>.
And exactly that info is the reason why one may want to execute libc.
|
There's also the fact that an executable libc is a nice way to
circumvent a 'noexec' restriction on a mount point :-)
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Brian M. Carlson *nix forums beginner
Joined: 21 Feb 2005
Posts: 28
|
Posted: Sat Feb 19, 2005 7:20 pm Post subject:
Re: execturing libc
|
|
|
On Fri, 2005-02-04 at 09:20 +0100, Wouter Verhelst wrote:
| Quote: | On Thu, Feb 03, 2005 at 04:31:02PM +0100, Goswin von Brederlow wrote:
mrvn@frosties:~% /lib64/ld-linux-x86-64.so.2 /lib/libc-2.3.2.so
GNU C Library stable release version 2.3.2, by Roland McGrath et al.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.3.5 (Debian 1:3.3.5-6).
Compiled on a Linux 2.6.0-test7 system on 2005-01-12.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
NPTL 0.60 by Ulrich Drepper
BIND-8.2.3-T5B
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
Report bugs using the `glibcbug' script to <bugs@gnu.org>.
And exactly that info is the reason why one may want to execute libc.
There's also the fact that an executable libc is a nice way to
circumvent a 'noexec' restriction on a mount point
|
I don't think libc has to be executable; simply
running /lib/ld-linux.so.2 /file/on/noexec/partition will work just
fine. And personally, I wouldn't disable the executable bit
on /lib/ld-2.3.2.so; I don't know what it might do.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Bernd Eckenfels *nix forums Guru Wannabe
Joined: 21 Feb 2005
Posts: 148
|
Posted: Sat Feb 19, 2005 7:20 pm Post subject:
Re: execturing libc
|
|
|
In article <20050204082016.GC28597@grep.be> you wrote:
| Quote: | There's also the fact that an executable libc is a nice way to
circumvent a 'noexec' restriction on a mount point
|
Are you refering to the ld.so trick which use to work or another one?
Greetings
Bernd
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Bernd Eckenfels *nix forums Guru Wannabe
Joined: 21 Feb 2005
Posts: 148
|
Posted: Sat Feb 19, 2005 7:20 pm Post subject:
Re: execturing libc
|
|
|
In article <1107507057.6328.23.camel@localhost> you wrote:
| Quote: | I don't think libc has to be executable; simply
running /lib/ld-linux.so.2 /file/on/noexec/partition will work just
fine.
|
I think recent ynamic linkers prevent this from beeing abused on noexec
media. However there is no reliable way to check any existing execute
prevention from the linkers POV.
Gruss
Bernd
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Tim Cutts *nix forums beginner
Joined: 08 Aug 2002
Posts: 30
|
Posted: Sat Feb 19, 2005 7:20 pm Post subject:
Re: Who could be able to help SW vendors to support Debian?
|
|
|
On 3 Feb 2005, at 5:53 pm, Eric Lavarde wrote:
| Quote: | Hi,
as I understand myself as someone aware of the support problems of
software problems, I would like to point to 2 problems:
1. the Debian Kernel is a bit different from the kernel.org Kernel;
example: at work we used the Apani VPN client, which did work under
all kind of RedHat/SuSE kernel, but not under the Debian kernel, even
though there is some compiling done at installation time (i.e. not
only binary modules delivered).
|
The RedHat kernel is considerably further diverged from kernel.org than
Debian's is. This is one of the major issues I have with vendors only
supporting Red Hat; Red Hat apply all sorts of patches and God knows
what to their kernel.
| Quote: | 2. as a software provider, you need to be able to reproduce the
problem of your customer to solve it (at least for non-obvious
problems), so that you can reproduce the problem in your environment,
debug, correct and test again. (I would also imagine there could be
some legal implications if you are officially supporting a certain
setup, but practically aren't able to support it properly; but we want
to stay out of the court ).
What is the consequence? you need a limited amount of possible
combinations, you need to have a stable system (in the sense: not
changing every three weeks) and you would greatly appreciate to be
informed of changes that might break your system before your customer
actually installs the patch/update/whatever.
Imagine a customer doing regularly an apt-get update & upgrade in
order to be sure to have the latest security fixes, and all of a
sudden, your expensive software stops to work, at all of your
customers, almost at once. You're out of business!
|
Well, this sort of thing happens with Red Hat AS as well. We've been
having immense problems with it lately for Oracle.
Well, I'd hope you'd test the upgrade on a development machine first.
I agree that the continuous upgrade cycle of testing and unstable
is not suitable for a support matrix for an ISV. It's one reason why
Debian really needs to get Sarge out of the door - ISVs will only
support stable releases, and Debian's stable releases are too few and
far between.
| Quote: | I'm exagerating a bit but that's what they want: no surprise, be able
to clearly define what is supported and what not (e.g. self compiled
kernel or not?!), have a chance to test before their own customers do.
|
I understand what you're getting at, but nevertheless my example stands
to show that ISV's can and do support purely on the basis of kernel and
C library. Platform Computing have been working that way with LSF for
years, and I haven't noticed them going out of business.
In their case this is because they only link against the really
fundamental system libraries:
11:41:03 tjrc@rlx-1-2-3:~$ ldd
/usr/local/lsf/5.1/linux2.4-glibc2.3-x86/etc/lim
libpthread.so.0 => /lib/libpthread.so.0 (0x4001e000)
libm.so.6 => /lib/libm.so.6 (0x4006f000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40092000)
libdl.so.2 => /lib/libdl.so.2 (0x400a7000)
libc.so.6 => /lib/libc.so.6 (0x400aa000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
and the lim daemon is the only part of LSF which is really
architecture-specific, and even then it doesn't do anything really
scary; it just reads stuff out of /proc. Hence the fact that their
support matrix requires certain kernel versions.
Regards,
Tim
--
Dr Tim Cutts
GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Google
|
|
| Back to top |
|
 |
|
|
The time now is Thu Jan 08, 2009 2:28 pm | All times are GMT
|
|
Loans | Debt Consolidation | Debt Consolidation | Loans | Debt Consolidation
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|