[Vserver] Kernel panic when running strace inside a vserver
Hello, I'm using kernel 2.6.17.1 with vsever patch vs2.1.1-rc24. Kernel panic when i try to use strace inside vserver (i can reproduce it while straceing qmail-smtpd and/or clamd-queue proces). Oops from netconsole in attachement. Jarek Dylag [42949720.46] [ cut here ] [42949720.46] kernel BUG at kernel/exit.c:732! [42949720.46] invalid opcode: [#1] [42949720.46] SMP [42949720.46] Modules linked in: ipt_LOG ipt_owner xt_state xt_tcpudp iptable_filter ipt_MASQUERADE iptable_nat ip_nat ip_tables x_tables af_key netconsole e100 ip_conntrack_ftp ip_conntrack nfnetlink [42949720.46] CPU:1 [42949720.46] EIP:0060:[c011bc7e]Not tainted VLI [42949720.46] EFLAGS: 00010006 (2.6.17.1p4smp.32 #1) [42949720.46] EIP is at forget_original_parent+0x1b3/0x223 [42949720.46] eax: ebx: d8a3a030 ecx: dde1eadc edx: dde1ea70 [42949720.46] esi: dde1ea70 edi: dfecea70 ebp: d46cdf48 esp: d46cdf34 [42949720.46] ds: 007b es: 007b ss: 0068 [42949720.46] Process clamd-queue (pid: 8139[#2149], threadinfo=d46cc000 task=dde1ea70) [42949720.46] Stack: d46cdf58 dde1eadc c79ade80 dde1ea70 dde1ea70 d46cdf6c c011bdb6 dde1ea70 [42949720.46] d46cdf58 d46cdf58 d46cdf58 c79ade80 d111a2c0 dde1ea70 d46cdf90 c011c2ea [42949720.46] dde1ea70 dde1ea70 0001 4700 ced10b40 4700 d46cc000 d46cdfa8 [42949720.47] Call Trace: [42949720.47] c01035c6 show_stack_log_lvl+0x7f/0x87 c0103724 show_registers+0x11f/0x188 [42949720.47] c010392d die+0x129/0x20f c04fd6b4 do_trap+0x6e/0x8a [42949720.47] c0103bf2 do_invalid_op+0x90/0x97 c0103273 error_code+0x4f/0x54 [42949720.47] c011bdb6 exit_notify+0xc8/0x26c c011c2ea do_exit+0x390/0x3dc [42949720.47] c011c3db sys_exit_group+0x0/0x12 c011c3eb sys_exit_group+0x10/0x12 [42949720.47] c01026d7 syscall_call+0x7/0xb [42949720.47] Code: 08 e9 d1 fe ff ff 8b 55 08 8b 5a 6c 89 d0 8b 0b 89 4d f0 83 c0 6c 39 c3 74 79 83 eb 74 8b 87 90 04 00 00 39 83 90 04 00 00 74 32 unparseable log message: 0f 0b dc 02 69 d6 52 c0 3b 3d 0c 52 5b c0 74 22 50 ff b7 a0 00 [42949720.47] History: SEQ: 49ee NR_CPUS: 8 [42949720.47] (#4903,*0):c048d1cf set_vx_info ca584000[#2149,85.28] @d334cd28 [42949720.47] (#48d6,*1):c048c079 clr_vx_info ca584000[#2149,78.26] @dea76328 [42949720.47] (#48e2,*2):c0116b6a set_vx_info ca584000[#2149,82.28] @d90b9f24 [42949720.47] (#4917,*3):c0116b6a set_vx_info ca584000[#2149,87.26] @dea3e424 [42949720.47] (#49db,*0):c01187e9 claim_vx_info ca584000[#2149,78.24] @ddde8550 [42949720.47] (#49ee,*1):c0103824 oops [42949720.47] (#49e7,*2):c01187e9 claim_vx_info ca584000[#2149,81.25] @dde1ea70 [42949720.47] (#49e8,*3):c0116b6a set_vx_info ca584000[#2149,81.26] @d30d9224 [42949720.47] (#49da,*0):c0116b6a set_vx_info ca584000[#2149,77.24] @dce61aa4 [42949720.47] (#49ed,*1):c012fff4 release_vx_info ca584000[#2149,83.27] @dde1ea70 [42949720.47] (#49e6,*2):c0116b6a set_vx_info ca584000[#2149,80.25] @debb74e4 [42949720.47] (#49e1,*3):c0116b6a set_vx_info ca584000[#2149,80.26] @d30d9c24 [42949720.47] (#49d9,*0):c011789c init_vx_info ca584000[#2149,76.24] @ddde89d8 [42949720.47] (#49ec,*1):c01187e9 claim_vx_info ca584000[#2149,83.26] @d8a3a030 [42949720.47] (#49e5,*2):c011789c init_vx_info ca584000[#2149,79.25] @dde1eef8 [42949720.47] (#49dc,*3):c0116b6a set_vx_info ca584000[#2149,78.25] @df58a2a4 [42949720.47] (#49d4,*0):c048c079 clr_vx_info ca584000[#2149,75.24] @dc756828 [42949720.47] (#49eb,*1):c0116b6a set_vx_info ca584000[#2149,82.26] @d30d9224 [42949720.47] (#49e2,*2):c0116c57 clr_vx_info ca584000[#2149,81.26] @debb74e4 [42949720.47] (#49c6,*3):c01187e9 claim_vx_info ca584000[#2149,76.24] @d75b4030 [42949720.47] (#49d3,*0):c048d1cf set_vx_info ca584000[#2149,74.24] @dc756828 [42949720.47] (#49ea,*1):c011789c init_vx_info ca584000[#2149,81.26] @d8a3a4b8 [42949720.47] (#49e0,*2):c01187e9 claim_vx_info ca584000[#2149,80.25] @df595a70 [42949720.47] (#49c5,*3):c0116b6a set_vx_info ca584000[#2149,75.24] @de43f7e4 [42949720.47] (#49d2,*0):c048c079 clr_vx_info ca584000[#2149,75.24] @dc756828 [42949720.47] (#49e9,*1):c0116c57 clr_vx_info ca584000[#2149,82.26] @d30d9224 [42949720.47] (#49df,*2):c0116b6a set_vx_info ca584000[#2149,79.25] @debb74e4 [42949720.47] (#49c4,*3):c011789c init_vx_info ca584000[#2149,74.24] @d75b44b8 [42949720.47] (#49d1,*0):c048d1cf set_vx_info ca584000[#2149,74.24] @dc756828 [42949720.47] (#49e4,*1):c0116c57 clr_vx_info ca584000[#2149,80.25] @d30d9c24 [42949720.47] (#49de,*2):c011789c init_vx_info ca584000[#2149,78.25] @df595ef8 [42949720.47] (#49c3,*3):c01187e9
Re: [Vserver] Re: [Devel] Container Test Campaign
Hi, In general - please don't get the impression I try to be fastidious. I'm just trying to help you create a system in which results can be reproducible and trusted. There are a lot of factors that influence the performance; some of those are far from being obvious. Don't get me wrong I'm looking for such remarks :) IMO you should add a reboot here, in between _different_ tests, just because previous tests should not influence the following ones. Certainly you do not need a reboot before iterations of the same test. I don't do this first because I didn't want to get test nodes wasting their time rebooting instead of running test. What do you think of something like this: o reboot o run dbench (or wathever) X times o reboot For test inside a 'guest' I just do something like: o build the appropriate kernel (2.6.16-026test014-x86_64-smp for example) o reboot Here you do not have to reboot. OpenVZ tools does not require OpenVZ kernel to be built. You got me... I was still believing the VZKERNEL_HEADERS variable was needed. Things have changed since vzctl 3.0.0-4... o build the utilities (vztcl+vzquota for example) o reboot o launch a guest Even this part is tricky! You haven't specified whether you create the guest before or after the reboot. Let me explain. If you create a guest before the reboot, the performance (at least at the first iteration) could be a bit higher than if you create a guest after the reboot. The reason is in the second case the buffer cache will be filled with OS template data (which is several hundred megs). can I can split the launch a guest part into 2 parts: o guest creation o reboot o guest start-up Do you feel comfortable with that? -The results are the average value of several iterations of each set of these kind of tests. Hope you do not recompile the kernels before the iterations (just to speed things up). I will try to update the site with the numbers of iterations behind each values. Would be great to have that data (as well as the results of the individual iterations, and probably graphs for the individual iterations -- to see the warming progress, discrepancy between iterations, degradation over iterations (if that takes place) etc). I will try to get/show those datas. The same will happen with most of the other tests involving I/O. Thus, test results will be non-accurate. To achieve more accuracy and exclude the impact of the disk and filesystem layout to the results, you should reformat the partition you use for testing each time before the test. Note that you don't have to reinstall everything from scratch -- just use a separate partition (mounted to say /mnt/temptest) and make sure most of the I/O during the test happens on that partition. It would be possible for 'host' node... inside the 'guest' node, I don't know if it makes sense. Just adding an 'external' partition to the 'guest' for I/O test purpose? For example in an OpenVZ guest, creating a new and empty simfs partition in order to run test on it? - For the settings of the guest I tried to use the default settings (I had to change some openvz guest settings) just following the HOWTO on vserver or openvz site. For the kernel parameters, did you mean kernel config file tweaking? No I mean those params from /proc/sys (== /etc/sysctl.conf). For example, if you want networking for canOpenVZ guests, you have to turn on ip_forwarding. There are some params affecting network performance, such as various gc_thresholds. For the big number of guests, you have to tune some system-wide parameters as well. For the moment, I just follow the available documentation: http://wiki.openvz.org/Quick_installation#Configuring_sysctl_settings Do you think these paramenters can hardly affect network performance? From what I understand lot of them are needed. - All binaries are always build in the test node. I assuming you are doing your tests on the same system (i.e. same compiler/libs/whatever else), and you do not change that system over time (i.e. you do not upgrade gcc on it in between the tests). I hope! :) -- Clément Calmels [EMAIL PROTECTED] ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: [Devel] Container Test Campaign
Clément Calmels wrote: What do you think of something like this: o reboot o run dbench (or wathever) X times o reboot Perfectly fine with me. Here you do not have to reboot. OpenVZ tools does not require OpenVZ kernel to be built. You got me... I was still believing the VZKERNEL_HEADERS variable was needed. Things have changed since vzctl 3.0.0-4.. Yes, we get rid off that dependency, to ease the external packages maintenance. can I can split the launch a guest part into 2 parts: o guest creation o reboot o guest start-up Do you feel comfortable with that? Perfectly fine. Same scenario applies to other cases: the rule of thumb is if your test preparation involves a lot of I/O, you'd better reboot in between preparation and the actual test. The same will happen with most of the other tests involving I/O. Thus, test results will be non-accurate. To achieve more accuracy and exclude the impact of the disk and filesystem layout to the results, you should reformat the partition you use for testing each time before the test. Note that you don't have to reinstall everything from scratch -- just use a separate partition (mounted to say /mnt/temptest) and make sure most of the I/O during the test happens on that partition. It would be possible for 'host' node... inside the 'guest' node, I don't know if it makes sense. Just adding an 'external' partition to the 'guest' for I/O test purpose? For example in an OpenVZ guest, creating a new and empty simfs partition in order to run test on it? simfs is not a real filesystem, it is kinda 'pass-though' fake FS which works on top of a real FS (like ext2 or ext3). So, in order to have a new fresh filesystem for guests, you can create some disk partition, mkfs and mount it to /vz. If you want to keep templates, just change the TEMPLATE variable in /etc/vz/vz.conf from /vz/template to something outside of /vz. There are other ways possible, and I think the same applies to VServer. - For the settings of the guest I tried to use the default settings (I had to change some openvz guest settings) just following the HOWTO on vserver or openvz site. For the kernel parameters, did you mean kernel config file tweaking? No I mean those params from /proc/sys (== /etc/sysctl.conf). For example, if you want networking for canOpenVZ guests, you have to turn on ip_forwarding. There are some params affecting network performance, such as various gc_thresholds. For the big number of guests, you have to tune some system-wide parameters as well. For the moment, I just follow the available documentation: http://wiki.openvz.org/Quick_installation#Configuring_sysctl_settings Do you think these paramenters can hardly affect network performance? From what I understand lot of them are needed. OK. Still, such stuff should be documented on the test results pages. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Re: linux-vserver patch 2.0.x for kernel 2.6.16
On Monday 03 July 2006 17:29, Herbert Poetzl wrote: On Mon, Jul 03, 2006 at 11:27:32AM +0200, Bert De Vuyst wrote: Dear Herbert, Is it possible to maintain a linux-vserver patch for the kernel 2.6.16.x series? I think so, who is going to maintain it? euh - kernel 2.6.16 is the kernel used by some large distributions for there next release (fedora and suse ?) Some people prefer to run the kernel version shipped with there distribution. (RedHat and SUSE) - kernel 2.6.16 did receive a large number of fixes. Some people will use it as there stable kernel for the next months. (they will skip 2.6.17) well, 2.6.17 should have all that fixes, no? Yes, it should have them. But if we look at the recent discussions regarding to the number of bugs inside the linux kernel, it did turn out that the number of bugs did increase in the more recent kernel releases. I think people will see kernel 2.6.16.x as a well tested, proven version. Large organizations tend to standardize there software on one version (in this case: one kernel release) if there is great demand and/or some good reason to do that, we will probably go that way ... Well, let's see when vs-2.0.2 is finished. We can then ask the mailinglist if there is a demand for it. Best regards, Bert. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: linux-vserver patch 2.0.x for kernel 2.6.16
Herbert Poetzl wrote: I think so, who is going to maintain it? if you give me the diffs between rc's, i'll keep them up to date for 2.6.16 (as i'm not that fond of 2.6.17 kernel just yet... i'll wait for a 2.6.17.20 or so, before i consider that one stable) as for grsec + vserver patches, i'm afraid i'll have to go to 2.6.17 rather fast, since spender doesn't support 2.6.16 kernels anymore... when vs2.0.2 comes out, and grsec 2.1.9, i'll try to fix a general patch for 2.6.16 aswell as 2.6.17, if people are still interested in 2.6.16 by then :) well, 2.6.17 should have all that fixes, no? problem is, that 2.6.17 has a lot of new code == bugs. (just check that sctp connection tracking stuff... it's... horrible. if there is great demand and/or some good reason to do that, we will probably go that way ... what's the ETA on vs2.0.2 ? what are the issues on that one? greetz, -- harry aka Rik Bobbaers K.U.Leuven - LUDIT -=- Tel: +32 485 52 71 50 [EMAIL PROTECTED] -=- http://harry.ulyssis.org Work hard and do your best, it'll make it easier for the rest -- Garfield Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: [Devel] Container Test Campaign
- All binaries are always build in the test node. I assuming you are doing your tests on the same system (i.e. same compiler/libs/whatever else), and you do not change that system over time (i.e. you do not upgrade gcc on it in between the tests). I hope! :) All binaries should be built statically to work the same way inside host/guest or you need to make sure that you have exactly the same versions of glibc and other system libraries. At least glibc can affect perforamnce very much :/ Kirill ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: [Devel] Container Test Campaign
On Tue, Jul 04, 2006 at 06:32:04PM +0400, Kirill Korotaev wrote: from the tests: For benchs inside real 'guest' nodes (OpenVZ/VServer) you should take into account that the FS tested is not the 'host' node one's. at least for Linux-VServer it should not be hard to avoid the chroot/filesystem namespace part and have it run on the host fs. a bind mount into the guest might do the trick too, if you need help to accomplish that, just let me know ... For the moment I just use the chcontext command to get rid of filesystem part. But even if the tested filesystem is not the host filesystem, I just keep in mind that all applications running inside a 'guest' will use _this_ filesystem and not the host one. From what I understand about VServer, it looks flexible enougth to let us test different 'virtualisation' parts. A 'guest' looks like a stack of different 'virtualisation' layers (chcontext + ipv4root + chroot). But it's not the case for all solutions. For OpenVZ it is also possible to test different subsytems separately (virtualization/isolation, resource management, disk quota, CPU scheduler). I would notice also, that in OpenVZ all these features are ON by default. which is the same as for a complete guest setup, what I think (and you already mentioned too, IIRC) is that it is very important to have identical test setups with and without virtualization enabled, which means that the following conditions are met: - filesystem and involved devices are identical - used resources and limits are identical/very close - number of processes and cache state as close as possible - kernel/system state as close as possible So I probably miss something, but why we test other technologies in modes when not all the features are ON? doesn't make much sense, and is not what I actually suggested in the first place, it might be interesting to narrow down possible issues by putting together a complete 'stack' slice by slice if that allows to remove a single slice from that equation in this case we compare not the real overhead, but the one minimized for this concrete benchmark. actually all cases are interesting as none of them is supposed to add measurable overhead which is also true for the whole thing which is at least the sum of all of them HTC, Herbert It's just like comparing with Xen Domain0 which doesn't have any overhead, but not because it is a good technology, but rather because it doesn't do anything valuable. BTW, comparing with Xen would be interesting as well. Just to show the difference. Thanks, Kirill ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Re: dist-upgrade problem with breezy
Replying to self. Someone else might find this useful. - Create /etc/vservers/vserver-name/bcapabilites - Add the following line: CAP_SYS_ADMIN The mount should work now. Question is now should keep that capability? Philippe Philippe Clérié wrote: I'm trying to dist-upgrade a breezy guest and getting an error when upgrading the initscripts package. The error occurs while running the postinst script, when it tries this: mount -n --bind / /.root The output from that is: mount: permission denied. I suspect I need to enable some capability to allow the mount. So far I haven't found a clue and I thought I'd ask. What is the minimum capability needed for this? And what are the downsides, if any? Is there any other way? Thanks in advance Philippe ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Error at vserver startup
Hi list! When I issue the command: vserver hibernia1 start --then it outputs as follows: vserver hibernia1 start Starting system logger: [ OK ] Starting kernel logger: [ OK ] Starting partmon: [ OK ] error: Operation not permitted setting key kernel.printk error: Operation not permitted setting key kernel.printk error: Operation not permitted setting key kernel.printk Setting mixer settings aumix: error opening mixer [FAILED] error: Operation not permitted setting key kernel.printk Starting crond: [ OK ] Starting kheader: [ OK ] I am using Mandriva 2006, the kernel version is 2.6.16-vs2.1.1-rc15 and the utils-vserver version packages are util-vserver-0.30.210-4mdk. Any ideas? Thanks in advance! -- Sergio Belkin Soluciones Informáticas Open Source Mandriva Authorized Solutions Provider http://www.escritorioya.com.ar (011) 4788-8605 // Cel. 15-5494-5143 ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Failed to startup v_sshd
Hi list: I don understand why it fails when v_sshd starts, this is the /var/log/messages: Jul 5 09:29:21 hibernia sshd[8430]: error: Bind to port 22 on 192.168.1.5 failed: Cannot assign requested address. Jul 5 09:29:21 hibernia sshd[8430]: fatal: Cannot bind any address. Jul 5 09:29:21 hibernia sshd: startup succeeded Greets- -- Sergio Belkin Soluciones Informáticas Open Source Mandriva Authorized Solutions Provider http://www.escritorioya.com.ar (011) 4788-8605 // Cel. 15-5494-5143 ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: [Devel] Container Test Campaign
Clément Calmels wrote: I don't do this first because I didn't want to get test nodes wasting their time rebooting instead of running test. What do you think of something like this: o reboot o run dbench (or wathever) X times o reboot [ ... ] I can split the launch a guest part into 2 parts: o guest creation o reboot o guest start-up Do you feel comfortable with that? we need to add a methodology page or similar on http://lxc.sourceforge.net/bench/ first page is a bit rough for the moment. -The results are the average value of several iterations of each set of these kind of tests. Hope you do not recompile the kernels before the iterations (just to speed things up). I will try to update the site with the numbers of iterations behind each values. Would be great to have that data (as well as the results of the individual iterations, and probably graphs for the individual iterations -- to see the warming progress, discrepancy between iterations, degradation over iterations (if that takes place) etc). I will try to get/show those datas. this data is already rougly available : http://lxc.sourceforge.net/bench/r3/dbenchraw http://lxc.sourceforge.net/bench/r3/tbenchraw etc. is that what you are thinking about ? - All binaries are always build in the test node. I assuming you are doing your tests on the same system (i.e. same compiler/libs/whatever else), and you do not change that system over time (i.e. you do not upgrade gcc on it in between the tests). I hope! :) all host nodes are described here : http://lxc.sourceforge.net/bench/r3/r3.html may be add the list of installed packages ? thanks, C. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: [Devel] Container Test Campaign
Kirill Korotaev wrote: - All binaries are always build in the test node. I assuming you are doing your tests on the same system (i.e. same compiler/libs/whatever else), and you do not change that system over time (i.e. you do not upgrade gcc on it in between the tests). I hope! :) All binaries should be built statically to work the same way inside host/guest or you need to make sure that you have exactly the same versions of glibc and other system libraries. At least glibc can affect perforamnce very much :/ yep. we could add a test line with the static versions. C. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: [Devel] Container Test Campaign
On Tue, Jul 04, 2006 at 04:19:02PM +0400, Kir Kolyshkin wrote: [lot of stuff zapped here] The different configs used are available in the lxc site. You will notice that I used a minimal config file for most of the test, but for Openvz I had to use the one I found in the OpenVZ site because I faced kernel build error (some CONFIG_NET... issues). We are trying to eliminate those, so a bug report would be nice. this might be some help here ... http://plm.osdl.org/plm-cgi/plm?module=patch_infopatch_id=5108 http://plm.osdl.org/plm-cgi/plm?module=patch_infopatch_id=5109 HTH, Herbert [zapped even more] ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Failed to startup v_sshd
On Wednesday 05 July 2006 14:31, Sergio Belkin wrote: Hi list: I don understand why it fails when v_sshd starts, this is the /var/log/messages: Jul 5 09:29:21 hibernia sshd[8430]: error: Bind to port 22 on 192.168.1.5 failed: Cannot assign requested address. Jul 5 09:29:21 hibernia sshd[8430]: fatal: Cannot bind any address. Jul 5 09:29:21 hibernia sshd: startup succeeded It fails because another process is already listening to 0.0.0.0:22 (probably on the host). Try to bind your hosts sshd to Listen only to a single IP fex. by adding ListenAddress 192.168.1.1 to your hosts /etc/ssh/sshd_config file (or any other place depending on your chosen distribution). Restart sshd and try it again. -- Christian Heim [EMAIL PROTECTED] Gentoo Linux Developer - vserver/openvz pgpATbO4WKGfI.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Failed to startup v_sshd
El Miércoles, 5 de Julio de 2006 13:14, Christian Heim escribió: On Wednesday 05 July 2006 14:31, Sergio Belkin wrote: Hi list: I don understand why it fails when v_sshd starts, this is the /var/log/messages: Jul 5 09:29:21 hibernia sshd[8430]: error: Bind to port 22 on 192.168.1.5 failed: Cannot assign requested address. Jul 5 09:29:21 hibernia sshd[8430]: fatal: Cannot bind any address. Jul 5 09:29:21 hibernia sshd: startup succeeded It fails because another process is already listening to 0.0.0.0:22 (probably on the host). Try to bind your hosts sshd to Listen only to a single IP fex. by adding ListenAddress 192.168.1.1 to your hosts /etc/ssh/sshd_config file (or any other place depending on your chosen distribution). Restart sshd and try it again. Christian, I did what you said but the problem lasts, When I run service v_sshd status it outputs as follow: exec /usr/sbin/chbind --ip eth0 /etc/init.d/sshd status ipv4root is now (public IP host) sshd dead but subsys locked And when vserver starts the messages are: Starting system logger: [ OK ] Starting kernel logger: [ OK ] Starting partmon: [ OK ] error: Operation not permitted setting key kernel.printk error: Operation not permitted setting key kernel.printk error: Operation not permitted setting key kernel.printk Setting mixer settings aumix: error opening mixer [FAILED] error: Operation not permitted setting key kernel.printk Starting crond: [ OK ] Starting kheader: [ OK ] Any suggestion? thanks in advance! -- Sergio Belkin Soluciones Informáticas Open Source Mandriva Authorized Solutions Provider http://www.escritorioya.com.ar (011) 4788-8605 // Cel. 15-5494-5143 ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] sshd creates /dev/pts/*, how can I create a /dev/pts/rob with an init.d script?
Salve Herbert, ML! Herbert Poetzl schrieb am Sonntag, den 02. Juli 2006 um 17:59h: What should I read to learn what fd,pts stands for and to know what /dev/pts/[14|20|21|31-34] are? *phew* good question, probably a lot of source code :) thing is, fd and pts (/14,/20 ...) are 'just' names used for character and block device nodes, identified by the unique major and minor identifiers ... so, basically c:136:14 means the 14th pseudo terminal (regardless of the name, could as well be named hansi) Could it by that I'm allowed to remove devices, but not allowed to create one? Exactly. Giving guests the ability to create devices is a huge security risk, basically equivalent to just giving access to the host directly. Whats about the pseudo terminals? sshd, screen ... and some others can create new ones as [EMAIL PROTECTED] :) asterisk seems like to have an own terminal: # from [Asterist-Users] ML Tzafrir Cohen wrote on # Tue Jul 4 09:05:46 MST 2006 # safe_asterisk has a flawed logic: it assumes that the tty device will # always exist. Thus it is not suited for use with screen. I used ln -s /dev/pts/31 /dev/tty9 successful, but on the next day /usr/sbin/safe_asterisk does not found /dev/tty9. /dev/pts/31 exist only for my bash, after exiting this bash, also /dev/pts/31 has been gone, and so this hack does not work... ;( How can I create with /etc/init.d/asterisk a new pseudo terminal, e.g. /dev/pts/ast and ln -s /dev/pts/ast /dev/tty9 Dirty trick would be to start with /etc/init.d/asterisk a ssh or telnet connection to 127.0.0.1, is there a smart way to create pseudo terminal, especialy that this terminal is durable and do not fade away when something crashed? device nodes are always local, so they cannot be 'forwarded' to another host, OTOH, you are free to create fifos (pipes) and symlinks to 'redirect' stuff remotely and local [EMAIL PROTECTED] mknode . /dev/pts/asterisk [EMAIL PROTECTED] ln -s /dev/pts/asterisk /dev/tty9 ??? #mknod /dev/tty9 c 7 7 mknod: »/dev/tty9«: Die Operation ist nicht erlaubt (operatin is not allowed) And mknod /dev/tty9 -p as FIFO does not help to run asterisk with a console. I found this: # From: Herbert Poetzl herbert_at_13thfloor.at # Date: Wed 17 May 2006 - 18:13:50 BST # Message-ID: [EMAIL PROTECTED] # On Sun, May 14, 2006 at 09:48:20PM -0700, EKC wrote: # I'm running a perl script inside of a linux vserver, and the script # requires access to tty and pty devices. However /dev/MAKEDEV and # mknod # cannot create pty devices from within a vserver. [...] # Is there a way to add devices from within a vserver itself? #pts/ptmx is auto created inside a guest, with proper #permissions and security (tty and pty are not required #inside a guest, unless you want to assign certain 'real' #consoles to the guest, like vt0/1/2 etc) ok and how can I use this magic auto creation inside a guest with/for /etc/init.d/asterisk? ;) man ptmx getpt(3), grantpt(3), ptsname(3), unlockpt(3) still a little bit too comlex for me ;( man expect man screen Well I could write #!/bin/sh # ttydumy.sh rm /dev/tty9 ln -s $tty /dev/tty9 and call screen .../ttydumy.sh inside safe_asterisk, but it seems that screen inside slows asterisk. (and this is ugly for ssh login and screen -r with multiple screens...) So [EMAIL PROTECTED] can indirectly create dumy devices and there is still no tool like mknode for vserver - because it is not so neccessary and does not have such a high priority - right? Dont't get me wrong, I don't want to be unpolite and I don't want to be missunderstood that expecting support and including of that feature It's just that I want to understand the power of vserver and to do the best with them and also try to document/promote them that it is possible to run an umpached asterisk with a colord CLI (Patching asterisk would be a second solution, would work for me but I think many vserver user would not do this...) Greetings, rob This is OT for Vserver ML, more for vserver+asterisk user: PS: My personal workaround at the moment: start screen and one of that terminal is used to get asterisk colored inside this terminal: tty /etc/asterisk/tty ln -s /dev/pts/$tty /dev/tty9 inside safe_asterisk a test if that device still exist... if yes TTY=tt9 so when asterisk crash and there is no TTY9 it will run without a hangup ;) ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Problem with vserver ethernet alias
Hello -- I've looked around in the archives but couldn't find anything similar to this situation. I have a server that is running Debian (sarge, kernel 2.6.11-vserver) and runs 4 vservers. Two of the vservers are webservers, which run Apache2. I am having troubles with the vserver named www in that when I add a 6th IP alias, it will not create the interface upon reboot. And until I remove that 6th definition and reboot again, the Apache2 server inside of vserver www will not start up, because the network did not initialize correctly. I have not had any troubles with adding these definitions until this time. If I manually do an ifconfig and add the interface by hand in the root server, then restart the www vserver and it's Apache2 server, then it's happy. I'm at a loss as to why on reboot, this 6th definition has a problem. I have it defined in /etc/vserver/www/interfaces/6 and have the files dev, ip, and name. The IP I'm using is unique and not conflicting with any of the other device aliases and the name I'm using for that interface is 8 characters long (and shorter than some of the other ones). If anyone has any ideas, it would be much appreciated. Thanks much -- Kathy [EMAIL PROTECTED] ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: dist-upgrade problem with breezy
On 7/5/06, Philippe Clérié [EMAIL PROTECTED] wrote: CAP_SYS_ADMIN Question is now should keep that capability? Depends if you want the admin for the vserver to have access to the whole machine. This capability is almost equal to giving somebody root on the host. D. blaze your trail -- redhat ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: [Devel] Container Test Campaign
On Wed, 05 Jul 2006 14:43:17 +0400, Kirill Korotaev wrote: - All binaries are always build in the test node. I assuming you are doing your tests on the same system (i.e. same compiler/libs/whatever else), and you do not change that system over time (i.e. you do not upgrade gcc on it in between the tests). I hope! :) All binaries should be built statically to work the same way inside host/guest or you need to make sure that you have exactly the same versions of glibc and other system libraries. At least glibc can affect perforamnce very much :/ Ick - no one builds binaries statically in the real world. And, when you build binaries statically, you lose all ability to fix security problems in base libraries by doing an update of that library. Instead, all applications need to be rebuilt. Performance tests should reflect real end user usage - not contrived situations that make a particular solution look better or worse. If glibc can affect performance, that should be demonstrated in the real performance results - it is part of the impact of the solution and may need an additional solution or discussion. gerrit ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
