Re: [Vserver] Announce - Bastard Patchset (version 0.13d)
mandag 29. dec 2003 kl. 02:07 skrev Herbert Poetzl: On Sun, Dec 28, 2003 at 10:53:54PM +0100, Jon Bendtsen wrote: søndag 28. dec 2003 kl. 20:45 skrev Dariush Pietrzak: is a ssh login good enough? or do you need physical access ? it would be nice to have ability to run various kernels on it, that means that someone would have to have physical access to it if it wouldn't got up after reboot. Also some arrangement for reading printk messages and oops messages would be beneficial. why not add a remote unit, as described on the linux-vserver.org pages, that would allow remote reboot, and a serial console, nothing more should be needed for testing/development ... coool, i'll do that then. connect it to another server in your basement, and allow minicom to be run on that machine/account ... works for me ... and then you could get access as well. JonB ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Announce - Bastard Patchset (version 0.13d)
then how about setting up a donation page for some corporate sponsors to donate some SMP-capable hardware for me? Dual ppc would be nice, thank you very much. is an old dual p200mmx usefull ? Of course. -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 Namagumi namagomi namagoroshi ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Announce - Bastard Patchset (version 0.13d)
søndag 28. dec 2003 kl. 19:00 skrev Dariush Pietrzak: then how about setting up a donation page for some corporate sponsors to donate some SMP-capable hardware for me? Dual ppc would be nice, thank you very much. is an old dual p200mmx usefull ? Of course. is a ssh login good enough? or do you need physical access ? JonB ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Announce - Bastard Patchset (version 0.13d)
is a ssh login good enough? or do you need physical access ? it would be nice to have ability to run various kernels on it, that means that someone would have to have physical access to it if it wouldn't got up after reboot. Also some arrangement for reading printk messages and oops messages would be beneficial. -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 Namagumi namagomi namagoroshi ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Announce - Bastard Patchset (version 0.13d)
søndag 28. dec 2003 kl. 20:45 skrev Dariush Pietrzak: is a ssh login good enough? or do you need physical access ? it would be nice to have ability to run various kernels on it, that means that someone would have to have physical access to it if it wouldn't got up after reboot. Also some arrangement for reading printk messages and oops messages would be beneficial. i know, and i dont know what would require most resources (time || money) for me. 1) set my old server up as a testserver for you in my basement, giving you root shell access, and then this read these printk messages for you, resetting it, ... or 2) pull the disks out, and mail the hole boks to you. (okay, maybe the mainboard/cpu/memory, but thats probably more work than shipping the hole unit to you). After i got my new PB i'll move my current desktop to b e my server, and then i dont really need the old server... How ever the disks i need, and i cant do the changeover for at least another week. JonB ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Announce - Bastard Patchset (version 0.13d)
On Sun, Dec 28, 2003 at 10:53:54PM +0100, Jon Bendtsen wrote: søndag 28. dec 2003 kl. 20:45 skrev Dariush Pietrzak: is a ssh login good enough? or do you need physical access ? it would be nice to have ability to run various kernels on it, that means that someone would have to have physical access to it if it wouldn't got up after reboot. Also some arrangement for reading printk messages and oops messages would be beneficial. why not add a remote unit, as described on the linux-vserver.org pages, that would allow remote reboot, and a serial console, nothing more should be needed for testing/development ... connect it to another server in your basement, and allow minicom to be run on that machine/account ... works for me ... best, Herbert i know, and i dont know what would require most resources (time || money) for me. 1) set my old server up as a testserver for you in my basement, giving you root shell access, and then this read these printk messages for you, resetting it, ... or 2) pull the disks out, and mail the hole boks to you. (okay, maybe the mainboard/cpu/memory, but thats probably more work than shipping the hole unit to you). After i got my new PB i'll move my current desktop to b e my server, and then i dont really need the old server... How ever the disks i need, and i cant do the changeover for at least another week. JonB ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Announce - Bastard Patchset (version 0.13d)
hmm, I hope you followed the vserver bug fixes, and adapted them for ctx17, otherwise I cannot consider ctx17 very stable ... which bugfixes? I'm not aware of showstopper-bugs in ctx17. Oh, and sorry for the term 'stable', let's replace it with 'old', that way we can avoid having to synchronize what 'stable' actually means. what testing did you do, regarding xfs/freeswan mppe/cipe/openwall interaction with vserver? I tend to avoid enhancments/patches that could conflict with each-other, that's why I use openwall instead of grsec. I just need those features, it's not about 'cool' factor, so going the easiest route is prefered ( and ensures vitality of the project, overly-ambitious one-man-shows die horrible deaths..). Test instalation should be as easy as: wget http://eyck.forumakad.pl/woody/kernel-image-2.4.23-13d-generic_Generic.1.00_i386.deb dpkg -i kernel-image-2.4.23-13d-generic_Generic.1.00_i386.deb ( or you could apt-get install kernel-image-2.4.23-13d-generic ) -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 Namagumi namagomi namagoroshi ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Announce - Bastard Patchset (version 0.13d)
On Sat, Dec 27, 2003 at 11:12:03AM +0100, Dariush Pietrzak wrote: hmm, I hope you followed the vserver bug fixes, and adapted them for ctx17, otherwise I cannot consider ctx17 very stable ... which bugfixes? I'm not aware of showstopper-bugs in ctx17. for UP it's mostly okay, on SMP machines, there are some critical races, which either lock the machine or crash it ... - sys_alloc_s_info(), takes the uts_sem sys_new_s_context() calls it with the alloc_ctx_lock held - dynamic context allocation can block forever - possible race in sys_release_s_info() with access from procfs and various other places Oh, and sorry for the term 'stable', let's replace it with 'old', that way we can avoid having to synchronize what 'stable' actually means. what's in a name? that which we call a rose by any other name would smell as sweet ... what testing did you do, regarding xfs/freeswan mppe/cipe/openwall interaction with vserver? I tend to avoid enhancments/patches that could conflict with each-other, that's why I use openwall instead of grsec. I just need those features, it's not about 'cool' factor, so going the easiest route is prefered hmm, okay, so you 'assume' by using mostly 'unrelated' patches (or patches patching different areas of the kernel) you can 'assure' good quality (no interaction) well, I guess that might be valid for most patches, but you'll have to check them, to make sure ... anyway I consider this a good approach ;) (and ensures vitality of the project, overly-ambitious one-man-shows die horrible deaths..). which project? linux-vserver? do I have to expect the horrible death? ;) Test instalation should be as easy as: wget http://eyck.forumakad.pl/woody/kernel-image-2.4.23-13d-generic_Generic.1.00_i386.deb dpkg -i kernel-image-2.4.23-13d-generic_Generic.1.00_i386.deb ( or you could apt-get install kernel-image-2.4.23-13d-generic ) patches for non-debian distros are where? TIA, Herbert -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 Namagumi namagomi namagoroshi ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
RE: [Vserver] Announce - Bastard Patchset (version 0.13d)
*snip* Oh, and sorry for the term 'stable', let's replace it with 'old', that way we can avoid having to synchronize what 'stable' actually means. patches for non-debian distros are where? Does anyone else that has actually run Debian find this hilarious? old == Debian old != non-debian (patches) That just brightened my day... and btw, Dariush, you'd better not let any Debian zealots get word of your releasing a 2.4.23 .deb, they'll find you and burn you at the stake. Allen Parker Hardcore-Linux.net Running Gentoo proudly since May '03 1x Gentoo Linux-Vserver host 2x Gentoo Linux-Vserver contexts Stable as a rock! ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Announce - Bastard Patchset (version 0.13d)
for UP it's mostly okay, on SMP machines, there are some critical races, which either lock the machine or crash it ... Oh, then since noone else is interested in fixing old ctx then how about setting up a donation page for some corporate sponsors to donate some SMP-capable hardware for me? Dual ppc would be nice, thank you very much. I guess trying to patch preemptivness in would also trigger those bugs. what's in a name? that which we call a rose by any other name would smell as sweet ... RomeoJuliett, nice. I wouldn't trust blonde suicidial girls with vserver technical issues though... patches (or patches patching different areas of the kernel) you can 'assure' good quality (no interaction) No, by avoiding patches touching the same places I 1) reduce amount of work required to get those patches together. 2) reduce the amount of problems that arise from banging those together. If there would be no time and equipment constraints I would create whole kernel myself, and then write all the apps in language that I would create. Unfortunatelly it seems like there are some teeny tiny constraints... you'll have to check them, to make sure ... Hmm, oh, right, it seemes like I dodged the question and haven't really answered it - I test first on my workstation, my setup is braindead enough that it's realatively good indication if something works fine on it. Then the kernel moves to my test server, this is k6-2-500 machine that has it's own history of finding bugs in lab-tested kernels. This machine is also populated with 'charlies', to borrow terminology from that obscure movie people are raving about. If it survives that I move it to production machines, then I fix small glitches that usually surface that night and change version to uneven number. It's not like I'm developing anything myself, most of quality assurance gets done by SGI - after they got burned by ptrace bug their really stringent about what they put in their xfs-kernel CVS. Since the only other tree I trusted - ac is on sabbatical I think this is the best approach I could take. For example - there is OOM missing from 2.4.23. This is huge change, if I would just use 2.4.23 I'd be dead in the water - I run some embedded machines, without OOM they would be disfunctional after few days/weeks of running. But luckily I do read changelogs sometimes, and more importantly so does SGI kernel team. So now both SGI xfs tree and my cute little bastard are based on 2.4.24rc4, which AFAIK still includes OOM. (and ensures vitality of the project, overly-ambitious one-man-shows die horrible deaths..). For example - 'folk', which was two-man-show IIRC. I don't recall it even compiling properly once. ( or you could apt-get install kernel-image-2.4.23-13d-generic ) patches for non-debian distros are where? http://eyck.forumakad.pl/Projects/bsd/ 13e should appear there soon enough ( i'm using unison from cron to distribute/mirror those when bandwidth is cheap, so it should be there in the morning ). -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 Namagumi namagomi namagoroshi ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Announce - Bastard Patchset (version 0.13d)
Running Gentoo proudly since May '03 that's nothing.. how about: Growing beard since 1995. -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
RE: [Vserver] Announce - Bastard Patchset (version 0.13d) - OT
Lol, I *still* can't grow one! (not a full one anyway, and I'm 22! Damn my father's Native American blood!) -Original Message- From: [EMAIL PROTECTED] [mailto:vserver- [EMAIL PROTECTED] On Behalf Of Dariush Pietrzak Sent: Saturday, December 27, 2003 3:05 PM To: [EMAIL PROTECTED] Subject: Re: [Vserver] Announce - Bastard Patchset (version 0.13d) Running Gentoo proudly since May '03 that's nothing.. how about: Growing beard since 1995. -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Announce - Bastard Patchset (version 0.13d)
On Sat, Dec 27, 2003 at 01:05:10AM +0100, Dariush Pietrzak wrote:
Hi,
I have been maintaining server kernel patchset for some time now...
I figure someone else could be interested in it, it should be available
from http://eyck.forumakad.pl/Projects/bsd/, latest version is 13d, later
this year I'll release 13e.
The goal of this patchset is making sure that:
- latest bug-free(;) linux(2.4.23-rc4)
- xfs filesystem
- vserver(ctx17)
- freeswan, mppe cipe
- openwall
play nicely together.
(additionaly this time around I include esfq {enhanced stochastic queueing},exec
logging from honeynet project, u32 target for iptables and sysctl control
for ip_queue).
This is not bleeding-edge, this is supposed to be stable platform for
rarely-updated machines. Components are kept relatively up-to-date but with
focus on stability - that's the reason for 2.4.23-rc4, ctx17 etc...
hmm, I hope you followed the vserver bug fixes,
and adapted them for ctx17, otherwise I cannot
consider ctx17 very stable ...
what testing did you do, regarding xfs/freeswan
mppe/cipe/openwall interaction with vserver?
best,
Herbert
--
Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9
Namagumi namagomi namagoroshi
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
