Re: Xen paravirtualized domU doesn't start
Oded ,
I have Fedora Core 6 on an i386 mahine ; I had used a Virtual
Machine Monitor to create and start a domU. (which is para virtualized
and FC6 based). This Virtual Machine Monitor is part of the Fedora
Core 6 installation.
(Applications-Systems Tools-Virtual Machine Monitor).
It works without any problems.
Installation is quite simple, and you can find a step by step description here:
http://wiki.xensource.com/xenwiki/XenIntro#head-b92d8b84fba2c72099710afd1027e8eafdad0f98
Regards,
Rami Rosen
On 11/29/06, Oded Arbel [EMAIL PROTECTED] wrote:
--=-3LD+5Pxn+/qCKd/a9nM3
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi list - a Xen question for the Xen masters out there, if you please.
I have a Fedora Core 6 with Xen 3.0.3 installed which is running a Cent
OS 4.4 on a fully virtualized domU (all this on an EM64T dual-cpu). The
cpuinfo claims I have VT support, but I'm not very happy with the
performance I'm getting (the VM stutters a lot and is generally very
slow and painful).
So I decided to try to paravirtualize it. I downloaded a RHEL 4.4 kernel
RPM from XenSource web site, and installed in on both the disk image the
vm is running from, and in my host. I then modified the vm config file
to look like this:
snip
name = sub1
## builder = hvm
memory = 512
disk = [ 'file:/var/xen/sub1/hda,hda,w' ]
vif = [ 'mac=00:16:3e:35:fe:9c, bridge=xenbr0', ]
uuid = 7fb7a5f3-199c-df57-3556-ba823c98b372
## device_model = /usr/lib64/xen/bin/qemu-dm
## kernel = /usr/lib/xen/boot/hvmloader
vnc=1
vncunused=1
#pae=1
#bootloader=/usr/bin/pygrub
initrd = /boot/xeninitrd
kernel = /boot/xenkernel
root = /dev/hda1 ro
vcpus=1
## serial = pty # enable serial console
on_reboot = 'restart'
on_crash= 'restart'
snap
(commented out lines is the values used for the fully-virtualized
setup).
Now when I try to start the VM, I get:
# xm create -c sub1
Using config file /etc/xen/sub1.
Error: (22, 'Invalid argument')
and this log in the xend.log:
snip
[2006-11-29 12:39:43 xend.XendDomainInfo 2655] DEBUG
(XendDomainInfo:190) XendDomainInfo.create(['vm', ['name', 'sub1'],
['memory', '512'], ['on_reboot', 'restart'], ['on_crash', 'restart'],
['vcpus', 1], ['uuid', '7fb7a5f3-199c-df57-3556-ba823c98b372'],
['image', ['linux', ['kernel', '/boot/xenkernel'], ['root', '/dev/hda1
ro'], ['vnc', 1], ['vncunused', 1], ['display', 'localhost:10.0'],
['xauthority', '/root/.Xauthority']]], ['device', ['vbd', ['uname',
'file:/var/xen/sub1/hda'], ['dev', 'hda'], ['mode', 'w']]], ['device',
['vif', ['bridge', 'xenbr0'], ['mac', '00:16:3e:35:fe:9c')
[2006-11-29 12:39:43 xend.XendDomainInfo 2655] DEBUG
(XendDomainInfo:296) parseConfig: config is ['vm', ['name', 'sub1'],
['memory', '512'], ['on_reboot', 'restart'], ['on_crash', 'restart'],
['vcpus', 1], ['uuid', '7fb7a5f3-199c-df57-3556-ba823c98b372'],
['image', ['linux', ['kernel', '/boot/xenkernel'], ['root', '/dev/hda1
ro'], ['vnc', 1], ['vncunused', 1], ['display', 'localhost:10.0'],
['xauthority', '/root/.Xauthority']]], ['device', ['vbd', ['uname',
'file:/var/xen/sub1/hda'], ['dev', 'hda'], ['mode', 'w']]], ['device',
['vif', ['bridge', 'xenbr0'], ['mac', '00:16:3e:35:fe:9c'
[2006-11-29 12:39:43 xend.XendDomainInfo 2655] DEBUG
(XendDomainInfo:395) parseConfig: result is {'shadow_memory': None,
'uuid': '7fb7a5f3-199c-df57-3556-ba823c98b372', 'on_crash': 'restart',
'on_reboot': 'restart', 'localtime': None, 'image': ['linux', ['kernel',
'/boot/xenkernel'], ['root', '/dev/hda1 ro'], ['vnc', 1], ['vncunused',
1], ['display', 'localhost:10.0'], ['xauthority', '/root/.Xauthority']],
'on_poweroff': None, 'bootloader_args': None, 'cpus': None, 'name':
'sub1', 'backend': [], 'vcpus': 1, 'cpu_weight': None, 'features': None,
'vcpu_avail': None, 'memory': 512, 'device': [('vbd', ['vbd', ['uname',
'file:/var/xen/sub1/hda'], ['dev', 'hda'], ['mode', 'w']]), ('vif',
['vif', ['bridge', 'xenbr0'], ['mac', '00:16:3e:35:fe:9c']])],
'bootloader': None, 'cpu': None, 'maxmem': None}
[2006-11-29 12:39:43 xend.XendDomainInfo 2655] DEBUG
(XendDomainInfo:1253) XendDomainInfo.construct: None
[2006-11-29 12:39:43 xend.XendDomainInfo 2655] DEBUG
(XendDomainInfo:1285) XendDomainInfo.initDomain: 4 1.0
[2006-11-29 12:39:43 xend 2655] INFO (image:214) configuring linux guest
[2006-11-29 12:39:43 xend 2655] INFO (image:232) setting use_graphics
[2006-11-29 12:39:43 xend 2655] DEBUG (balloon:127) Balloon: 524780 KiB
free; need 524288; done.
[2006-11-29 12:39:43 xend 2655] INFO (image:138) buildDomain os=linux
dom=4 vcpus=1
[2006-11-29 12:39:43 xend 2655] DEBUG (image:193) dom= 4
[2006-11-29 12:39:43 xend 2655] DEBUG (image:194) image
= /boot/xenkernel
[2006-11-29 12:39:43 xend 2655] DEBUG (image:195) store_evtchn = 1
[2006-11-29 12:39:43 xend 2655] DEBUG (image:196) console_evtchn = 2
[2006-11-29 12:39:43 xend 2655] DEBUG (image:197) cmdline=
root=/dev/hda1 ro
[2006-11-29 12:39:43 xend 2655] DEBUG (image:198) ramdisk=
[2006-11-29 12:39:43 xend 2655] DEBUG (image:199)
Re: Xen paravirtualized domU doesn't start
On Thu, 2006-11-30 at 10:09 +0200, Rami Rosen wrote: Oded , I have Fedora Core 6 on an i386 mahine ; I had used a Virtual Machine Monitor to create and start a domU. (which is para virtualized and FC6 based). This Virtual Machine Monitor is part of the Fedora Core 6 installation. (Applications-Systems Tools-Virtual Machine Monitor). It works without any problems. Yes, I've used it also - but it only works if you are creating a new virtual machine, and then only if the new virtual machine is Fedora Core 6 (or possibly other operating systems that has a Xen kernel out-of-the-box). I want to run CentOS 4, with a 3rd party kernel package, and worse - I want to convert a fully-virtualized vm to a para-virtualized one, because I don't care to reinstall the vm. Thanks anyway. -- Oded ::.. You can build a throne with bayonets, but you can't sit on it for long. -- Boris Yeltsin = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
The Linux Installation Process Presentation on 3-December-2006 in Telux (W2L)
[Resending with a corrected subject line] Hi all! On Sunday, 3-December-2006 , the Tel Aviv Linux club will hold its The Linux Installation Process presentation as part of the Welcome to Linux presentation series. The presentation will take place at 18:30 in room Shenkar 222 (Physics Astronomy Building) of Tel Aviv University. The presenter will be Zohar Snir. Some ad-hoc slides (update to Mandriva 10.1) can be found here: http://vipe.technion.ac.il/~adir/lectures/MandrakeInstLect.pdf After the Welcome-to-Linux series, we would like to resume our regular presentations, and so if you have an idea for a presentation, please let us know. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: To: Ira / Warning: could not send message for past 10 hours (fwd)
On Wed, 2006-11-29 at 22:36 +0200, Peter wrote: .. while talking to kelly.abramov.org.: RCPT To:[EMAIL PROTECTED] 451 ;z; Dynamic IP pool blocked due to zombie infestation. See http://rbl.eonspace.net/?rblip=192.114.44.226/21 for details [EMAIL PROTECTED]... Deferred: 451 ;z; Dynamic IP pool blocked due to zombie infestation. See http://rbl.eonspace.net/?rblip=192.114.44.226/21 for details One small nitpick: Some dolt blocked an IP block that is indeed zombied, but in fact it is two IP blocks. Both are in Bulgaria, and both are infested (you should see my webserver's log). BUT I am not in Bulgaria and I have an IP that is sandwiched between the Bulgarians, from Actcom. And I have no zombie here (at least not in the computer). I'm not sure if you are referring to the above quoted rejection, or to something else, but the block 192.114.44.226/21 from which you tried to send e-mail to Ira Abramov is indeed Actcom dial-up pool, which rbl.eonspace.net blocks only this specific pool and nothing else (no Bulgarians here). So trigger-happy blacklisters are not exactly my favorite hereoes. Never were. Who knows how many people do not get my email because of such things. I am personally not very happy with the situation where RBLs (mine included) *need* to block dynamic IPs. I'm well aware that many people (and many on this list) are running their own MTAs - and quite legitimately - on their dynamic dial-up IP. Unfortunately, there is simply no way to block zombies while not blocking such kosher setups, and for that reason all MTAs support the option of relaying all outgoing SMTP traffic through an ISP mail server, that will deliver your e-mail correctly - because you already pay your ISP for this service. Not taking advantage of a service you pay for and then complaining that you get blocked is not, IMHO, a valid stance. -- Oded ::.. Freshly reinstalled computers are a bit like a pair of new shoes - you're happy that you've finally got a new pair, but they're awkward to use for a little while. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: To: Ira / Warning: could not send message for past 10 hours (fwd)
On Thu, 30 Nov 2006, Oded Arbel wrote: One small nitpick: Some dolt blocked an IP block that is indeed zombied, but in fact it is two IP blocks. Both are in Bulgaria, and both are infested (you should see my webserver's log). BUT I am not in Bulgaria and I have an IP that is sandwiched between the Bulgarians, from Actcom. And I have no zombie here (at least not in the computer). I'm not sure if you are referring to the above quoted rejection, or to something else, but the block 192.114.44.226/21 from which you tried to send e-mail to Ira Abramov is indeed Actcom dial-up pool, which rbl.eonspace.net blocks only this specific pool and nothing else (no Bulgarians here). FYI there are about as many zombie computers in Israel as anywhere else, but Israeli (and Asian) IP blocks are more likely to get blacklisted than others. The 'neighbors' are/were Bulgarians (I think, from the name) (80.130. etc). Now it's someone else. I send out all my email via my ISP's MTA as relay. This means that someone blocked Actcom's main MTA SMTP origin. If the zombies also send through that then I can understand it. Else not. Afaik zombies do not use the MTA of the ISP. They are not that disciplined. Or weren't. I *always* send mail with origin [EMAIL PROTECTED] via Actcom's MTA. The rule is hardwired in the transports map, and has been for four years or so. So trigger-happy blacklisters are not exactly my favorite hereoes. Never were. Who knows how many people do not get my email because of such things. I am personally not very happy with the situation where RBLs (mine included) *need* to block dynamic IPs. I'm well aware that many people (and many on this list) are running their own MTAs - and quite legitimately - on their dynamic dial-up IP. Unfortunately, there is simply no way to block zombies while not blocking such kosher setups, and for that reason all MTAs support the option of relaying all outgoing SMTP traffic through an ISP mail server, that will deliver your e-mail correctly - because you already pay your ISP for this service. Not taking advantage of a service you pay for and then complaining that you get blocked is not, IMHO, a valid stance. As I said, that is not the case. My IP is in the 85.130 group but the IP blocked belongs to the Actcom origin servers, and is NOT a dynamic IP. I think that I know what I am doing here, most of the time anyway. Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: To: Ira / Warning: could not send message for past 10 hours (fwd)
On Nov 30, 11:50, Oded Arbel wrote: } Subject: Re: To: Ira / Warning: could not send message for past 10 hours ( On Wed, 2006-11-29 at 22:36 +0200, Peter wrote: .. while talking to kelly.abramov.org.: RCPT To:[EMAIL PROTECTED] 451 ;z; Dynamic IP pool blocked due to zombie infestation. See http://rbl.eonspace.net/?rblip=192.114.44.226/21 for details [EMAIL PROTECTED]... Deferred: 451 ;z; Dynamic IP pool blocked due to zombie infestation. See http://rbl.eonspace.net/?rblip=192.114.44.226/21 for details One small nitpick: Some dolt blocked an IP block that is indeed zombied, but in fact it is two IP blocks. Both are in Bulgaria, and both are infested (you should see my webserver's log). BUT I am not in Bulgaria and I have an IP that is sandwiched between the Bulgarians, from Actcom. And I have no zombie here (at least not in the computer). I'm not sure if you are referring to the above quoted rejection, or to something else, but the block 192.114.44.226/21 from which you tried to send e-mail to Ira Abramov is indeed Actcom dial-up pool, which rbl.eonspace.net blocks only this specific pool and nothing else (no Bulgarians here). If you mean 192.114.40.0/21 (the /21 block which 192.114.44.226 belongs to), the 192.114.44.0/24 range is indeed dynamic dialup (modem/ADSL). Most of the other IPs in this /21 are not dialup, so if somebody blocked the whole /21 it was according to a bad guess. Anyone that sends mail directly from his link needs a static IP, which PTR which is equal to his domain (the regular PTR something.broadband.actcom.net.il is blocked almost anywhere due to the broadband string and/or due to the IP in the something part). So trigger-happy blacklisters are not exactly my favorite hereoes. Never were. Who knows how many people do not get my email because of such things. If a user that needs direct mailing happens to have a blocked IP, we can just replace it (providing that it is a static IP). But EVERY IP has a very big chance to be BLOCKED SOMEWHERE (this can be even stated every IP is blocked in really many places). Amir I am personally not very happy with the situation where RBLs (mine included) *need* to block dynamic IPs. I'm well aware that many people (and many on this list) are running their own MTAs - and quite legitimately - on their dynamic dial-up IP. Unfortunately, there is simply no way to block zombies while not blocking such kosher setups, and for that reason all MTAs support the option of relaying all outgoing SMTP traffic through an ISP mail server, that will deliver your e-mail correctly - because you already pay your ISP for this service. Not taking advantage of a service you pay for and then complaining that you get blocked is not, IMHO, a valid stance. -- Oded ::.. Freshly reinstalled computers are a bit like a pair of new shoes - you're happy that you've finally got a new pair, but they're awkward to use for a little while. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: To: Ira / Warning: could not send message for past 10 hours (fwd)
Quoting Peter, from the post of Wed, 29 Nov: were. Who knows how many people do not get my email because of such things. you should, unless you ignore bounces. Sadly, I'm forced to ignore all bounces not originating by my own server since at least one if not more spammers are bombing the world with fake return addresses from abramov.org, ira.abramov.org and scso.com (and maybe others). -- Not Actual Size Ira Abramov http://ira.abramov.org/email/ = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: To: Ira / Warning: could not send message for past 10 hours (fwd)
On Thu, 2006-11-30 at 12:12 +0200, Peter wrote: FYI there are about as many zombie computers in Israel as anywhere else, Correct but Israeli (and Asian) IP blocks are more likely to get blacklisted than others. Not correct. The main reason I'm running my own RBL, is that most Israeli dyanmic IP pools are not blocked by most or all RBLs. For example, the IP address you quoted as being rejected by my RBL - 192.114.44.226, when tested with robtex multi-rbl checking tool ( http://www.robtex.com/rbls.html ) comes up with a green bill of health. This means that someone blocked Actcom's main MTA SMTP origin. Then please notify Actcom support about it and let them handle it. You did call Actcom support, right ? As the old adage goes - when you make an omlete you need to break some eggs (כשחוטבים עצים, עפים שבבים). In the long war against SPAM, some people get hit by what is known in other circles as friendly fire. That being the case, the war itself is still a just cause and the battle shouldn't be abandoned because of a few stray shots hitting innocent victims. I *always* send mail with origin [EMAIL PROTECTED] via Actcom's MTA. The rule is hardwired in the transports map, and has been for four years or so. As I said, that is not the case. My IP is in the 85.130 group but the IP blocked belongs to the Actcom origin servers, and is NOT a dynamic IP. You are correct. I blocked the entire range 192.114.40.0/21 as a single block as its listed in RIPE as a single block (ACTCOM-BLOCK-3) although it contains both dynamic IP addresses as well as hosted services, including Actcom's own servers. This was my mistake and I changed the rules to only block 192.114.44,5,6/24. I think that having both dynamic IP pools and static IPs in the same block is wrong- exactly for this reason, as it makes it really easy to make mistakes and block IPs incorrectly. That being the case - I'm not going to stop blocking IPs that deliver SPAM, and as the RBL is (a) not listed anywhere, and (b) was initially described with a large enough warning label, I would also continue to block large IP blocks that I believe are also possible sources of SPAM. I would suggest to people who are using it to keep using it and I will try harder not to hit innocent bystanders. -- Oded ::.. Instructions for life: 9. Open your arms to change, but don't let go of your values. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: To: Ira / Warning: could not send message for past 10 hours (fwd)
On Nov 30, 12:12, Peter wrote: } Subject: Re: To: Ira / Warning: could not send message for past 10 hours ( On Thu, 30 Nov 2006, Oded Arbel wrote: One small nitpick: Some dolt blocked an IP block that is indeed zombied, but in fact it is two IP blocks. Both are in Bulgaria, and both are infested (you should see my webserver's log). BUT I am not in Bulgaria and I have an IP that is sandwiched between the Bulgarians, from Actcom. And I have no zombie here (at least not in the computer). I'm not sure if you are referring to the above quoted rejection, or to something else, but the block 192.114.44.226/21 from which you tried to send e-mail to Ira Abramov is indeed Actcom dial-up pool, which rbl.eonspace.net blocks only this specific pool and nothing else (no Bulgarians here). FYI there are about as many zombie computers in Israel as anywhere else, but Israeli (and Asian) IP blocks are more likely to get blacklisted than others. Indeed we use to get letters like: I got spam from 192.114.x.x, hence we blocked in our routers 192.114.0.0/16. Don't bother to answer. I.e., people also use to block Israeli addresses in their routers. The 'neighbors' are/were Bulgarians (I think, from the name) (80.130. etc). Now it's someone else. I send out all my email via my ISP's MTA as relay. This means that someone blocked Actcom's main MTA SMTP origin. If the zombies also send through that then I can understand it. Else not. Afaik zombies do not use the MTA of the ISP. They are not that disciplined. Or weren't. I *always* send mail with origin [EMAIL PROTECTED] via Actcom's MTA. The rule is hardwired in the transports map, and has been for four years or so. Some /8 blocks, like 85.0.0.0/8, are blocked all over the world in router ACL levels because once it was an unallocated block, and people published lists of such blocks, without mentioning one needs to update these ACLs from time to time. We have 85.130.128.0/17 and are suffering from that. Amir So trigger-happy blacklisters are not exactly my favorite hereoes. Never were. Who knows how many people do not get my email because of such things. I am personally not very happy with the situation where RBLs (mine included) *need* to block dynamic IPs. I'm well aware that many people (and many on this list) are running their own MTAs - and quite legitimately - on their dynamic dial-up IP. Unfortunately, there is simply no way to block zombies while not blocking such kosher setups, and for that reason all MTAs support the option of relaying all outgoing SMTP traffic through an ISP mail server, that will deliver your e-mail correctly - because you already pay your ISP for this service. Not taking advantage of a service you pay for and then complaining that you get blocked is not, IMHO, a valid stance. As I said, that is not the case. My IP is in the 85.130 group but the IP blocked belongs to the Actcom origin servers, and is NOT a dynamic IP. I think that I know what I am doing here, most of the time anyway. Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: To: Ira / Warning: could not send message for past 10 hours (fwd)
On Thu, Nov 30, 2006, Ira Abramov wrote about Re: To: Ira / Warning: could not send message for past 10 hours (fwd): were. Who knows how many people do not get my email because of such things. you should, unless you ignore bounces. Sadly, I'm forced to ignore all bounces not originating by my own server since at least one if not more spammers are bombing the world with fake return addresses from abramov.org, ira.abramov.org and scso.com (and maybe others). This is not a new phenomenon - several times in the past I've been bombarded by bounces of spam and viruses which I supposedly wrote (but in reality, obviously, someone faked my address as the sender of these messages). At some points in time, I actually got more of these spam bounces than real spams - sometimes hundreds a day. It's not very hard to recognize these misdirected bounces, while still receiving legitimate bounces. The key is that bounced mail contains the Message-id: that you sent in your own mail; Since spammers do not (currently) attempt to fake their Message-ids, you can recognize your real bounces from fake ones. For example, here is my procmail script which puts all fake bounces into a folder spambounces: :0 BH: *^from +MAILER-DAEMON[ @] * !^Message-id: [EMAIL PROTECTED] spambounces -- Nadav Har'El| Thursday, Nov 30 2006, 9 Kislev 5767 [EMAIL PROTECTED] |- Phone +972-523-790466, ICQ 13349191 |What's the greatest world-wide use of http://nadav.harel.org.il |cowhide? To hold cows together. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: To: Ira / Warning: could not send message for past 10 hours (fwd)
On Thu, 30 Nov 2006, Ira Abramov wrote: Quoting Peter, from the post of Wed, 29 Nov: were. Who knows how many people do not get my email because of such things. you should, unless you ignore bounces. Bounces ? What bounces. Your bounce was the first one in a year or so. I already told people to send an ok when they get mail from me because of that. Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
$150 laptop is alive (was $100)
With a good picture of it too (on page 2) http://www.nytimes.com/2006/11/30/technology/30laptop.html?_r=1hpex=1164862800en=303aca02ff156728ei=5094partner=homepageoref=slogin Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Biggest Open Source projects
Hi, in some place I read that the Linux Kernel is one of 3 largest Open Source projects (over 3 million LOC of C code). I wonder what are the other big Open Source projects? Are they all written in C or C++? Are ther big OS projects written in Java? What are the bigges projects in Perl/Python/Ruby ? Gabor = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Biggest Open Source projects
There's a nice site that collects statistics on open source projects. http://ohloh.org A lot of cool information there... -- Yarin http://yarinbenado.com On 11/30/06, Gabor Szabo [EMAIL PROTECTED] wrote: Hi, in some place I read that the Linux Kernel is one of 3 largest Open Source projects (over 3 million LOC of C code). I wonder what are the other big Open Source projects? Are they all written in C or C++? Are ther big OS projects written in Java? What are the bigges projects in Perl/Python/Ruby ? Gabor = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] -- Yarin Benado http://benado.net
Re: To: Ira / Warning: could not send message for past 10 hours (fwd)
I also got such a message: /-- - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 554 5.7.1 Service unavailable; Client host [192.114.47.35] blocked using rbl.eonspace.net; ;z; Dynam... blocked due to zombie infestation. See http://rbl.eonspace.net/?rblip=192.114.44.226/21 for details) \-- 192.114.47.35 is one of our mailers. Somebody blocked a whole range of 8 class-Cs because of one zombie mail from a client of us. Anyone doing such blocking in a large scale will loss much of his mail connectivity, and I guess it may not be a good idea to have mail service at an ISP with such a blocking policy. http://rbl.eonspace.net/?rblip=192.114.44.226/21 (and even http://rbl.eonspace.net or http://eonspace.net/) gives me a page with only this sentence: Put your new web site here So I cannot see any more details on who blocked it and how to unblock. Amir On Nov 30, 12:38, Amir Plivatsky wrote: } Subject: Re: To: Ira / Warning: could not send message for past 10 hours ( On Nov 30, 11:50, Oded Arbel wrote: } Subject: Re: To: Ira / Warning: could not send message for past 10 hours ( On Wed, 2006-11-29 at 22:36 +0200, Peter wrote: .. while talking to kelly.abramov.org.: RCPT To:[EMAIL PROTECTED] 451 ;z; Dynamic IP pool blocked due to zombie infestation. See http://rbl.eonspace.net/?rblip=192.114.44.226/21 for details [EMAIL PROTECTED]... Deferred: 451 ;z; Dynamic IP pool blocked due to zombie infestation. See http://rbl.eonspace.net/?rblip=192.114.44.226/21 for details One small nitpick: Some dolt blocked an IP block that is indeed zombied, but in fact it is two IP blocks. Both are in Bulgaria, and both are infested (you should see my webserver's log). BUT I am not in Bulgaria and I have an IP that is sandwiched between the Bulgarians, from Actcom. And I have no zombie here (at least not in the computer). I'm not sure if you are referring to the above quoted rejection, or to something else, but the block 192.114.44.226/21 from which you tried to send e-mail to Ira Abramov is indeed Actcom dial-up pool, which rbl.eonspace.net blocks only this specific pool and nothing else (no Bulgarians here). If you mean 192.114.40.0/21 (the /21 block which 192.114.44.226 belongs to), the 192.114.44.0/24 range is indeed dynamic dialup (modem/ADSL). Most of the other IPs in this /21 are not dialup, so if somebody blocked the whole /21 it was according to a bad guess. Anyone that sends mail directly from his link needs a static IP, which PTR which is equal to his domain (the regular PTR something.broadband.actcom.net.il is blocked almost anywhere due to the broadband string and/or due to the IP in the something part). So trigger-happy blacklisters are not exactly my favorite hereoes. Never were. Who knows how many people do not get my email because of such things. If a user that needs direct mailing happens to have a blocked IP, we can just replace it (providing that it is a static IP). But EVERY IP has a very big chance to be BLOCKED SOMEWHERE (this can be even stated every IP is blocked in really many places). Amir I am personally not very happy with the situation where RBLs (mine included) *need* to block dynamic IPs. I'm well aware that many people (and many on this list) are running their own MTAs - and quite legitimately - on their dynamic dial-up IP. Unfortunately, there is simply no way to block zombies while not blocking such kosher setups, and for that reason all MTAs support the option of relaying all outgoing SMTP traffic through an ISP mail server, that will deliver your e-mail correctly - because you already pay your ISP for this service. Not taking advantage of a service you pay for and then complaining that you get blocked is not, IMHO, a valid stance. -- Oded ::.. Freshly reinstalled computers are a bit like a pair of new shoes - you're happy that you've finally got a new pair, but they're awkward to use for a little while. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: To: Ira / Warning: could not send message for past 10 hours (fwd)
Quoting Amir Plivatsky, from the post of Thu, 30 Nov: I also got such a message: /-- - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 554 5.7.1 Service unavailable; Client host [192.114.47.35] blocked using rbl.eonspace.net; ;z; Dynam... blocked due to zombie infestation. See http://rbl.eonspace.net/?rblip=192.114.44.226/21 for details) To Oded's credit, I'll say he DID warn me from using his personal RBL :-) I guess 12 RBLs are enough to check against for now. Sorry Oded for the vote of inconfidence, but I'm removing our RBL from my list. -- Reinventing sigs Ira Abramov http://ira.abramov.org/email/ = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: To: Ira / Warning: could not send message for past 10 hours (fwd)
You are correct. I blocked the entire range 192.114.40.0/21 as a single block as its listed in RIPE as a single block (ACTCOM-BLOCK-3) although it contains both dynamic IP addresses as well as hosted services, including Actcom's own servers. This was my mistake and I changed the rules to only block 192.114.44,5,6/24. I think that having both dynamic IP pools and static IPs in the same block is wrong- exactly for this reason, as it makes it really easy to make mistakes and block IPs incorrectly. Just a comment for perspective to understand if it was originally a wrong thing: This (192.114.40.0/21) was the only block we had when we started as an ISP (marking it as ACTCOM-BLOCK-N was a letter thing). No one thought at those days about RBLs of dynamic IPs... Also, the number of IPs in any pool was very low, and of course we couldn't dedicate a whole /21 for them. So for historical reasons IPs of these blocks (and others) got used for various things. That being the case - I'm not going to stop blocking IPs that deliver SPAM, and as the RBL is (a) not listed anywhere, and (b) was initially described with a large enough warning label, I would also continue to block large IP blocks that I believe are also possible sources of SPAM. I would suggest to people who are using it to keep using it and I will try harder not to hit innocent bystanders. To my opinion, the best thing is to use RBLs for scoring in AntiSpam software instead of automatic rejecting any mail from certain blocks. However, we here also have our own list of rejected IP blocks, because the amount of spam from some blocks is so high it severely degrades the performance of the mail servers. In that cases we still allow mail to our abuse address, and the error message says mail [EMAIL PROTECTED] to unblock (and we occasionally get such requests). -- Oded ::.. Instructions for life: 9. Open your arms to change, but don't let go of your values. Amir = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Ethical question..
All Hypothetical... say you had a client you worked for. One day over lunch, one of the guys of the RD of a different product at the company tells you how they circumvent the kernel checks to load a non-GPL module and get all the symbols a GPL module gets. This is not exactly a GPL violation, however it makes a stock RHEL kernel be fooled to think this closed source module is actually GPL and give it access to more info than the kernel team wanted. What would you do? do you just protest but keep working there? make that information public? Inform lkml how they fooled the kernel without revieling the identity of the violators, just to help them patch it for the future? spill the beans on Slashdot? and what would you do if it was a real GPL violation? will a signed NDA with that company make a difference in your decision? Thanks, Ira. -- Just hold me Ira Abramov http://ira.abramov.org/email/ = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Ethical question..
On Thu, Nov 30, 2006 at 06:29:36PM +0200, Ira Abramov wrote: say you had a client you worked for. One day over lunch, one of the guys of the RD of a different product at the company tells you how they circumvent the kernel checks to load a non-GPL module and get all the symbols a GPL module gets. Yuck. This is not exactly a GPL violation, however it makes a stock RHEL kernel be fooled to think this closed source module is actually GPL and give it access to more info than the kernel team wanted. .. which means pretty much nothing from a technical POV. From an ethical POV... Yuck. What would you do? Depends. do you just protest but keep working there? Unlikely... as you can probably recall from a company we've both worked for in the past, people who don't respect licenses tend to not respect their employees or contractors either. Inform lkml how they fooled the kernel without revieling the identity of the violators, just to help them patch it for the future? The module GPL check is easily circumvented. It's not meant to defeat an attacker, just make the wishes of the kernel community with regards to licensing and external modules obvious. IMNEHO, if they're distributing a binary only module they're in violation of the kernel's license already. Circumventing the GPL check is just one more nail in the coffin. Cheers, Muli = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Ethical question..
To me, the dilemma would be about my corporate loyalty (to the company's success) and perhaps personal loyalty to the owners vs. loyalty to the community (can I even say public good?). Funny you mention an NDA here, cause I think that once you've set your mind about the community being more important, any juridical method to prohibit you from reporting the crime would be questionable, and anyhow it'd turn into a practical question for lawyers rather than an ethical question for hackers. On 11/30/06, Ira Abramov [EMAIL PROTECTED] wrote: and what would you do if it was a real GPL violation? will a signed NDA with that company make a difference in your decision? = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: To: Ira / Warning: could not send message for past 10 hours (fwd)
On Thu, 2006-11-30 at 17:36 +0200, Amir Plivatsky wrote: I also got such a message: /-- - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 554 5.7.1 Service unavailable; Client host [192.114.47.35] blocked using rbl.eonspace.net; ;z; Dynam... blocked due to zombie infestation. See http://rbl.eonspace.net/?rblip=192.114.44.226/21 for details) http://rbl.eonspace.net/?rblip=192.114.44.226/21 (and even http://rbl.eonspace.net or http://eonspace.net/) gives me a page with only this sentence: Put your new web site here So I cannot see any more details on who blocked it and how to unblock. Its my personal RBL, and I already fixed the problem - I made a mistake in not investigating the whole IP block as listed in RIPE records, and instead after a few examining reverse resolving on a few addresses I decided it was all a dial-up pool. This service is in development and I haven't finished the web front-end for that yet. -- Oded ::.. I have to post. Buddha insists on a warm computer. -- Keith Justified And Ancient Cochran = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Ethical question..
On Thu, Nov 30, 2006 at 06:29:36PM +0200, Ira Abramov wrote: say you had a client you worked for. One day over lunch, one of the guys of the RD of a different product at the company tells you how they circumvent the kernel checks to load a non-GPL module and get all the symbols a GPL module gets. I don't see what's wrong with that. It's a compromise that makes both parties win. The kernel stays GPL'ed, it loses nothing. The vendor makes his OCO (object code only) module available to whomever meets the critera he has, and they get to use it with Linux. If they don't want to use nonGLP'ed code with their Linux kernel, they simply don't load the vendor's module. It may mean a lost function for a customer, more likley it means a lost sale for the vendor. This is not exactly a GPL violation, however it makes a stock RHEL kernel be fooled to think this closed source module is actually GPL and give it access to more info than the kernel team wanted. I think in the U.S. that would be a violation of the DMCA. Do you want such laws here? Is this any different than SAMBA? Printer ink cartridges? DeCSS? What would you do? do you just protest but keep working there? No, you congratulate them on a job well done. You convince them to make a case for releasing the module as open source and help them promote it to the managment. Offer to extend your contract (and compensation) to help them make the switch and promote it. make that information public? No. Inform lkml how they fooled the kernel without revieling the identity of the violators, just to help them patch it for the future? No. They'll just work around it, abandon the product or go with BSD. spill the beans on Slashdot? Those ~@@[EMAIL PROTECTED] They'll just make a fool of you. The truth is the last thing they care about. and what would you do if it was a real GPL violation? Nothing. From my experience people in general and most of the people on this list only care when you are discussing it. If it affects something they want to use, or can make money on, the GPL is happily ignored. will a signed NDA with that company make a difference in your decision? No. An NDA will just get you sued faster, but you will be sued in the end. Consider it a CLM. Geoff. -- Geoffrey S. Mendelson, Jerusalem, Israel [EMAIL PROTECTED] N3OWJ/4X1GM IL Voice: (07)-7424-1667 Fax ONLY: 972-2-648-1443 U.S. Voice: 1-215-821-1838 Visit my 'blog at http://geoffstechno.livejournal.com/ = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: To: Ira / Warning: could not send message for past 10 hours (fwd)
On Thu, 2006-11-30 at 18:10 +0200, Ira Abramov wrote: Quoting Amir Plivatsky, from the post of Thu, 30 Nov: I also got such a message: /-- - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 554 5.7.1 Service unavailable; Client host [192.114.47.35] blocked using rbl.eonspace.net; ;z; Dynam... blocked due to zombie infestation. See http://rbl.eonspace.net/?rblip=192.114.44.226/21 for details) To Oded's credit, I'll say he DID warn me from using his personal RBL :-) I guess 12 RBLs are enough to check against for now. Sorry Oded for the vote of inconfidence, but I'm removing our RBL from my list. That's ok, though I did fix that problem, and I am being more careful about it from now on. (see my previous e-mail on the subject) -- Oded ::.. Q: What's tiny and yellow and very, very, dangerous? A: A canary with the super-user password. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
