Menu
▾
▴
devil-linux-discuss — General Mailing List for all discussions
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(59) |
Sep
(57) |
Oct
(5) |
Nov
(45) |
Dec
(21) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(13) |
Feb
(22) |
Mar
(14) |
Apr
(7) |
May
(33) |
Jun
(57) |
Jul
(25) |
Aug
(40) |
Sep
(53) |
Oct
(58) |
Nov
(75) |
Dec
(22) |
| 2003 |
Jan
(101) |
Feb
(101) |
Mar
(103) |
Apr
(125) |
May
(85) |
Jun
(57) |
Jul
(62) |
Aug
(42) |
Sep
(76) |
Oct
(214) |
Nov
(290) |
Dec
(274) |
| 2004 |
Jan
(187) |
Feb
(172) |
Mar
(313) |
Apr
(209) |
May
(169) |
Jun
(147) |
Jul
(118) |
Aug
(193) |
Sep
(227) |
Oct
(125) |
Nov
(246) |
Dec
(191) |
| 2005 |
Jan
(244) |
Feb
(175) |
Mar
(165) |
Apr
(130) |
May
(217) |
Jun
(122) |
Jul
(188) |
Aug
(235) |
Sep
(165) |
Oct
(133) |
Nov
(209) |
Dec
(88) |
| 2006 |
Jan
(66) |
Feb
(89) |
Mar
(108) |
Apr
(91) |
May
(29) |
Jun
(45) |
Jul
(64) |
Aug
(42) |
Sep
(44) |
Oct
(81) |
Nov
(64) |
Dec
(9) |
| 2007 |
Jan
(24) |
Feb
(122) |
Mar
(55) |
Apr
(50) |
May
(84) |
Jun
(13) |
Jul
(80) |
Aug
(70) |
Sep
(78) |
Oct
(45) |
Nov
(56) |
Dec
(42) |
| 2008 |
Jan
(65) |
Feb
(3) |
Mar
(51) |
Apr
(151) |
May
(54) |
Jun
(72) |
Jul
(73) |
Aug
(47) |
Sep
(55) |
Oct
(123) |
Nov
(16) |
Dec
(4) |
| 2009 |
Jan
(23) |
Feb
(39) |
Mar
(27) |
Apr
(36) |
May
(35) |
Jun
(51) |
Jul
(11) |
Aug
(14) |
Sep
(40) |
Oct
(67) |
Nov
(38) |
Dec
(13) |
| 2010 |
Jan
(15) |
Feb
(35) |
Mar
(40) |
Apr
(11) |
May
(26) |
Jun
(10) |
Jul
(5) |
Aug
(50) |
Sep
(86) |
Oct
(67) |
Nov
(36) |
Dec
(11) |
| 2011 |
Jan
(50) |
Feb
(6) |
Mar
(13) |
Apr
(13) |
May
(29) |
Jun
(27) |
Jul
(26) |
Aug
(27) |
Sep
(21) |
Oct
(7) |
Nov
(27) |
Dec
(4) |
| 2012 |
Jan
(11) |
Feb
(20) |
Mar
(48) |
Apr
(18) |
May
(8) |
Jun
(19) |
Jul
|
Aug
(15) |
Sep
(3) |
Oct
(4) |
Nov
(5) |
Dec
(1) |
| 2013 |
Jan
(13) |
Feb
(7) |
Mar
(4) |
Apr
(25) |
May
(2) |
Jun
(8) |
Jul
(4) |
Aug
(8) |
Sep
(7) |
Oct
|
Nov
(5) |
Dec
(10) |
| 2014 |
Jan
|
Feb
|
Mar
(6) |
Apr
(20) |
May
(5) |
Jun
|
Jul
(2) |
Aug
|
Sep
(8) |
Oct
(21) |
Nov
(4) |
Dec
(7) |
| 2015 |
Jan
(10) |
Feb
(9) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(11) |
Oct
|
Nov
(17) |
Dec
(32) |
| 2016 |
Jan
(10) |
Feb
(15) |
Mar
(4) |
Apr
(7) |
May
(10) |
Jun
(11) |
Jul
(15) |
Aug
(26) |
Sep
(13) |
Oct
(10) |
Nov
(16) |
Dec
(6) |
| 2017 |
Jan
(9) |
Feb
(3) |
Mar
|
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
(3) |
Sep
(3) |
Oct
(6) |
Nov
(8) |
Dec
|
| 2018 |
Jan
(12) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Heiko Z. <he...@zu...> - 2006-11-22 04:45:17
|
On Tue, November 21, 2006 14:29, Frank Weis wrote: > I'll happily test it, no problem. > BTW, I just received two of the nexcom nsa1042 appliances you suggested. > They ran with my CF-cards and usb-stick out-of-the-box. Nice stuff, for > about half the price of what we used to buy... thanks for the tip! I'm uploading right now, it should be finished around 6:30 your time. -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: drew e. <dre...@gm...> - 2006-11-21 21:13:39
|
Just took a look at the nexcom site and saw a bunch of interesting stuff, but no sales information. Where did you buy them? What do they cost? On 11/21/06, Frank Weis <Fra...@ct...> wrote: > I'll happily test it, no problem. > BTW, I just received two of the nexcom nsa1042 appliances you suggested. > They ran with my CF-cards and usb-stick out-of-the-box. Nice stuff, for about > half the price of what we used to buy... thanks for the tip! > > > Good Night, > > Frank > On Tuesday 21 November 2006 18:35, Heiko Zuerker wrote: > > On Tue, November 21, 2006 09:05, Frank Weis wrote: > > > Hi all Maintainers, > > > > > > > > > is there any specific reason why nagios and nrpe are missing in 1.2.11? > > > > > > I had them in some 1.2.11-xxxx but they didn't make it to the release... > > > > > > > > > I have some sites where DL exhibits some degradation (it continues to > > > operate but sshd refuses to let me in), and I would like to monitor and > > > see what happens to the resources just before things go bad... Is there > > > any other tool that I could use? > > > > It was only in one of the development versions, but I disabled it because > > of some file locations which where screwed up. > > Let me enable it and start a new compile, since I think most of the issues > > should be fixed. > > I just won't be able to verify it before I upload it, can you do that and > > let me know if nagios now works? > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Devil-linux-discuss mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss > -- Drew Einhorn |
|
From: Heiko Z. <he...@zu...> - 2006-11-21 20:28:46
|
On Tue, November 21, 2006 14:29, Frank Weis wrote: > I'll happily test it, no problem. > BTW, I just received two of the nexcom nsa1042 appliances you suggested. > They ran with my CF-cards and usb-stick out-of-the-box. Nice stuff, for > about half the price of what we used to buy... thanks for the tip! Awesome ! They didn't accidently send you a PCI riser card you don't need? ;-) (would need it for a 1041 anyway) -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Frank W. <Fra...@ct...> - 2006-11-21 20:06:29
|
I'll happily test it, no problem. BTW, I just received two of the nexcom nsa1042 appliances you suggested. They ran with my CF-cards and usb-stick out-of-the-box. Nice stuff, for about half the price of what we used to buy... thanks for the tip! Good Night, Frank On Tuesday 21 November 2006 18:35, Heiko Zuerker wrote: > On Tue, November 21, 2006 09:05, Frank Weis wrote: > > Hi all Maintainers, > > > > > > is there any specific reason why nagios and nrpe are missing in 1.2.11? > > > > I had them in some 1.2.11-xxxx but they didn't make it to the release... > > > > > > I have some sites where DL exhibits some degradation (it continues to > > operate but sshd refuses to let me in), and I would like to monitor and > > see what happens to the resources just before things go bad... Is there > > any other tool that I could use? > > It was only in one of the development versions, but I disabled it because > of some file locations which where screwed up. > Let me enable it and start a new compile, since I think most of the issues > should be fixed. > I just won't be able to verify it before I upload it, can you do that and > let me know if nagios now works? |
|
From: Heiko Z. <he...@zu...> - 2006-11-21 17:35:30
|
On Tue, November 21, 2006 09:05, Frank Weis wrote: > Hi all Maintainers, > > > is there any specific reason why nagios and nrpe are missing in 1.2.11? > > I had them in some 1.2.11-xxxx but they didn't make it to the release... > > > I have some sites where DL exhibits some degradation (it continues to > operate but sshd refuses to let me in), and I would like to monitor and > see what happens to the resources just before things go bad... Is there > any other tool that I could use? It was only in one of the development versions, but I disabled it because of some file locations which where screwed up. Let me enable it and start a new compile, since I think most of the issues should be fixed. I just won't be able to verify it before I upload it, can you do that and let me know if nagios now works? -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Matthew H. <mat...@va...> - 2006-11-21 15:10:47
|
Personally I would use syslog-ng to do remote syslogging and you really = should spot some usefuls bits of info in there. Cheers Mat -----Original Message----- From: dev...@li... = [mailto:dev...@li...] On Behalf Of = Frank Weis Sent: 21 November 2006 15:05 To: dev...@li... Subject: [Devil-Linux-discuss] Nagios, NRPE Hi all Maintainers, is there any specific reason why nagios and nrpe are missing in 1.2.11? I had them in some 1.2.11-xxxx but they didn't make it to the release... I have some sites where DL exhibits some degradation (it continues to = operate=20 but sshd refuses to let me in), and I would like to monitor and see what = happens to the resources just before things go bad... Is there any other = tool=20 that I could use? Thanks, Frank --=20 _______________________________________________ Centre de Technologie de l'Education 29 avenue John F. Kennedy L-1855 Luxembourg-Kirchberg email: Fra...@ct... t=E9l.: +352 478-5973 fax: +352 333797 _______________________________________________ -------------------------------------------------------------------------= Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share = your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV _______________________________________________ Devil-linux-discuss mailing list Dev...@li... https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss |
|
From: Frank W. <Fra...@ct...> - 2006-11-21 15:05:30
|
Hi all Maintainers, is there any specific reason why nagios and nrpe are missing in 1.2.11? I had them in some 1.2.11-xxxx but they didn't make it to the release... I have some sites where DL exhibits some degradation (it continues to opera= te=20 but sshd refuses to let me in), and I would like to monitor and see what=20 happens to the resources just before things go bad... Is there any other to= ol=20 that I could use? Thanks, =46rank =2D-=20 _______________________________________________ Centre de Technologie de l'Education 29 avenue John F. Kennedy L-1855 Luxembourg-Kirchberg email: Fra...@ct... t=E9l.: +352 478-5973 fax: +352 333797 _______________________________________________ |
|
From: Heiko Z. <he...@zu...> - 2006-11-21 04:06:45
|
On Mon, November 20, 2006 16:30, drew einhorn wrote: > Hmm. Has there been any consideration to moving DL to a 2.6 kernel? > As time goes by it's just going to get harder and harder to backport and > maintain applications to run on a 2.4 kernel. We don't have any concrete plans. There's still quite some work left on the development version (which uses 2.6) and I'm hoping to spend some time on it during the holiday season. Of course help is always welcome, anybody can check out the 1.3 tree and help is getting it to work. -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: drew e. <dre...@gm...> - 2006-11-20 22:55:57
|
Thanks, I'll take a look at it. And try posting to a list over at lartc.org. Drew On 11/20/06, cdmiller <cdm...@ad...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Not sure if it helps, but you may also want to look at bandwidth arbitrator: > > http://www.bandwidtharbitrator.com/ > > It does require a patched kernel so you would have to do a devil-linux > compilation. I had been planning to try it on Devil, just haven't > gotten around to it yet. > > - - cameron > > drew einhorn wrote: > > Trying again. Hope I'm finally off the bogus email blacklist, and > > this goes through. > > > > ---------- Forwarded message ---------- > > From: drew einhorn <dre...@gm...> > > Date: Nov 19, 2006 11:51 PM > > Subject: Traffic Shaping on a Transparent Bridge not working! > > To: dev...@li... > > > > > > My first DL project was going well. Then I ran into problems attempting > > to shape my bandwidth. > > > > First I'll describe the parts that I believe are working correctly. > > > > I have a DL 1.2.11 box running the default kernel, 2.4.33.3-grsec > > > > I have br0 bridging all four ports eth0, eth1, eth2, eth3 on a quad port > > pci card. The bridge has not been assigned an ip number on the theory > > that this makes it much more difficult to attack. The bridge connects > > four devices on the 3bit public static ip block from my ISP. > > > > I have a single port ethernet pci card, eth4 with a static ip, on my > > internal private ip network. It is used for remote managent of the DL > > box from anywhere on my internal network. > > > > eth0 is connected to my ISP's router via the ethernet port on my > > ISDN modem. I know ISDN is a nearly dead technology, but it's the best > > thing my crappy telco offers. Tried a satellite ISP, but that's another > > long story. > > > > eth1 is connected to a hardened publicly accessible host. > > > > eth2 and eth3 are connected to the WAN ports on a couple of Linksys > > Cable/DSL routers. Eventually most of their functions will migrate to the > > DL box, but that is more than I wanted to bite off in my first DL project. > > > > The first Linksys box NATs one of my public ips to my internal private > > ip network. The second Linksys box is newer and includes a wireless > > access point used by a couple neighbors. It NATs a second public ip to > > a separate private ip network. > > > > All of the above appears to be working as expected. > > > > After pondering the mysteries of traffic shaping I decided to start with > > wondershaper 1.1a from lartc.org, rather than starting from scratch. > > > > Tried both the cbq and htb versions without any success. > > > > RTFM time. The htb section of http://lartc.org/howto/index.html is easier > > reading than the cbq section. And the howto claims htb is better anyway. > > Let's focus on the htb version of wondershaper. > > > > OK, First we edit wshaper.htb and configure the shell variables. Then we > > run: sh -x wshaper.htb > > to echo the commands as they are executed. > > > > Then we start pinging the router at the other end of the ISDN line. > > > > Then we start downloading a file to generate some traffic that really > > needs to be shaped. > > > > Then we run: sh -x wshaper.htb status > > to gather some statistics > > > > then we kill the download. > > > > then we sh -x wshaper.htb stop to shut down the malfunctioning shaper. > > > > Here's the output from the ping: > > > > $ ping 67.0.192.10 > > PING 67.0.192.10 (67.0.192.10) 56(84) bytes of data. > > > > Link is idle, normal ping times. > > > > 64 bytes from 67.0.192.10: icmp_seq=0 ttl=254 time=48.5 ms > > 64 bytes from 67.0.192.10: icmp_seq=1 ttl=254 time=48.4 ms > > 64 bytes from 67.0.192.10: icmp_seq=2 ttl=254 time=48.4 ms > > 64 bytes from 67.0.192.10: icmp_seq=3 ttl=254 time=48.4 ms > > 64 bytes from 67.0.192.10: icmp_seq=4 ttl=254 time= 48.5 ms > > 64 bytes from 67.0.192.10: icmp_seq=5 ttl=254 time=67.8 ms > > 64 bytes from 67.0.192.10: icmp_seq=6 ttl=254 time=48.3 ms > > 64 bytes from 67.0.192.10: icmp_seq=7 ttl=254 time=48.2 ms > > > > Download starts. Shaping is not working! Queues in > > router and/or ISDN modem grow, and ping times rapidly > > become huge. > > > > 64 bytes from 67.0.192.10: icmp_seq=8 ttl=254 time=184 ms > > 64 bytes from 67.0.192.10: icmp_seq=9 ttl=254 time=1080 ms > > 64 bytes from 67.0.192.10: icmp_seq=10 ttl=254 time=2025 ms > > 64 bytes from 67.0.192.10: icmp_seq=11 ttl=254 time=1551 ms > > 64 bytes from 67.0.192.10: icmp_seq=12 ttl=254 time=1078 ms > > 64 bytes from 67.0.192.10: icmp_seq=13 ttl=254 time=896 ms > > 64 bytes from 67.0.192.10: icmp_seq=14 ttl=254 time=1088 ms > > 64 bytes from 67.0.192.10: icmp_seq=15 ttl=254 time=1171 ms > > 64 bytes from 67.0.192.10: icmp_seq=16 ttl=254 time=1272 ms > > 64 bytes from 67.0.192.10: icmp_seq=17 ttl=254 time=1280 ms > > 64 bytes from 67.0.192.10: icmp_seq=18 ttl=254 time=1101 ms > > 64 bytes from 67.0.192.10: icmp_seq=19 ttl=254 time=1258 ms > > 64 bytes from 67.0.192.10: icmp_seq=20 ttl=254 time=1211 ms > > 64 bytes from 67.0.192.10: icmp_seq=21 ttl=254 time=1259 ms > > 64 bytes from 67.0.192.10: icmp_seq=22 ttl=254 time=1373 ms > > 64 bytes from 67.0.192.10: icmp_seq=23 ttl=254 time=1424 ms > > 64 bytes from 67.0.192.10: icmp_seq=24 ttl=254 time=1461 ms > > 64 bytes from 67.0.192.10: icmp_seq=25 ttl=254 time=1277 ms > > 64 bytes from 67.0.192.10: icmp_seq=26 ttl=254 time=1521 ms > > 64 bytes from 67.0.192.10: icmp_seq=27 ttl=254 time=1467 ms > > 64 bytes from 67.0.192.10: icmp_seq=28 ttl=254 time=1335 ms > > 64 bytes from 67.0.192.10: icmp_seq=29 ttl=254 time=1329 ms > > 64 bytes from 67.0.192.10: icmp_seq=30 ttl=254 time=1386 ms > > 64 bytes from 67.0.192.10: icmp_seq=31 ttl=254 time=1360 ms > > 64 bytes from 67.0.192.10: icmp_seq=32 ttl=254 time=1416 ms > > 64 bytes from 67.0.192.10: icmp_seq=33 ttl=254 time=1480 ms > > 64 bytes from 67.0.192.10: icmp_seq=34 ttl=254 time=1345 ms > > 64 bytes from 67.0.192.10: icmp_seq=35 ttl=254 time=1356 ms > > 64 bytes from 67.0.192.10: icmp_seq=36 ttl=254 time=1370 ms > > 64 bytes from 67.0.192.10: icmp_seq=37 ttl=254 time=1278 ms > > 64 bytes from 67.0.192.10: icmp_seq=38 ttl=254 time=1612 ms > > 64 bytes from 67.0.192.10: icmp_seq=39 ttl=254 time=1520 ms > > 64 bytes from 67.0.192.10: icmp_seq=40 ttl=254 time=1322 ms > > 64 bytes from 67.0.192.10: icmp_seq=41 ttl=254 time=1545 ms > > > > Kill the download queues empty and ping times return to normal > > > > 64 bytes from 67.0.192.10 : icmp_seq=42 ttl=254 time=975 ms > > 64 bytes from 67.0.192.10: icmp_seq=43 ttl=254 time=67.4 ms > > 64 bytes from 67.0.192.10: icmp_seq=44 ttl=254 time= 73.6 ms > > 64 bytes from 67.0.192.10: icmp_seq=45 ttl=254 time=45.2 ms > > 64 bytes from 67.0.192.10: icmp_seq=46 ttl=254 time=45.2 ms > > 64 bytes from 67.0.192.10: icmp_seq=47 ttl=254 time=44.8 ms > > > > > > And, here's the shell commands and their output: > > > > root@Devil:~ # sh -x wshaper.htb > > + DOWNLINK=100 > > + UPLINK=100 > > + DEV=eth0 > > + NOPRIOHOSTSRC= > > + NOPRIOHOSTDST= > > + NOPRIOPORTSRC= > > + NOPRIOPORTDST= > > + '[' '' = status ']' > > + tc qdisc del dev eth0 root > > + tc qdisc del dev eth0 ingress > > + '[' '' = stop ']' > > + tc qdisc add dev eth0 root handle 1: htb default 20 > > + tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbit burst 6k > > + tc class add dev eth0 parent 1:1 classid 1:10 htb rate 100kbit burst 6k prio 1 > > + tc class add dev eth0 parent 1:1 classid 1:20 htb rate 90kbit burst 6k prio 2 > > + tc class add dev eth0 parent 1:1 classid 1:30 htb rate 80kbit burst 6k prio 2 > > + tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 > > + tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 > > + tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10 > > + tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip > > tos 0x10 0xff flowid 1:10 > > + tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip > > protocol 1 0xff flowid 1:10 > > + tc filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip > > protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 > > match u8 0x10 0xff at 33 flowid 1:10 > > + tc filter add dev eth0 parent 1: protocol ip prio 18 u32 match ip > > dst 0.0.0.0/0 flowid 1:20 > > + tc qdisc add dev eth0 handle ffff: ingress > > + tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip > > src 0.0.0.0/0 police rate 100kbit burst 10k drop flowid :1 > > > > > > root@Devil:~ # sh -x wshaper.htb status > > + DOWNLINK=100 > > + UPLINK=100 > > + DEV=eth0 > > + NOPRIOHOSTSRC= > > + NOPRIOHOSTDST= > > + NOPRIOPORTSRC= > > + NOPRIOPORTDST= > > + '[' status = status ']' > > + tc -s qdisc ls dev eth0 > > qdisc htb 1: r2q 10 default 20 direct_packets_stat 0 > > Sent 18649 bytes 191 pkts (dropped 0, overlimits 0) > > qdisc sfq 10: parent 1:10 limit 128p quantum 1514b perturb 10sec > > Sent 10582 bytes 147 pkts (dropped 0, overlimits 0) > > qdisc sfq 20: parent 1:20 limit 128p quantum 1514b perturb 10sec > > Sent 8067 bytes 44 pkts (dropped 0, overlimits 0) > > qdisc sfq 30: parent 1:30 limit 128p quantum 1514b perturb 10sec > > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > > qdisc ingress ffff: ---------------- > > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > > + tc -s class ls dev eth0 > > class htb 1:1 root rate 100000bit ceil 100000bit burst 6Kb cburst 1724b > > Sent 18649 bytes 191 pkts (dropped 0, overlimits 0) > > rate 1320bit 1pps > > lended: 0 borrowed: 0 giants: 0 > > tokens: 398459 ctokens: 108855 > > > > class htb 1:10 parent 1:1 leaf 10: prio 1 rate 100000bit ceil > > 100000bit burst 6Kb cburst 1724b > > Sent 10582 bytes 147 pkts (dropped 0, overlimits 0) > > rate 656bit 1pps > > lended: 147 borrowed: 0 giants: 0 > > tokens: 398459 ctokens: 108855 > > > > class htb 1:20 parent 1:1 leaf 20: prio 2 rate 90000bit ceil 90000bit > > burst 6Kb cburst 1711b > > Sent 8067 bytes 44 pkts (dropped 0, overlimits 0) > > rate 712bit > > lended: 44 borrowed: 0 giants: 0 > > tokens: 432284 ctokens: 109555 > > > > class htb 1:30 parent 1:1 leaf 30: prio 2 rate 80000bit ceil 80000bit > > burst 6Kb cburst 1699b > > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > > lended: 0 borrowed: 0 giants: 0 > > tokens: 503316 ctokens: 139264 > > > > + exit > > root@Devil:~ # sh -x wshaper.htb stop > > + DOWNLINK=100 > > + UPLINK=100 > > + DEV=eth0 > > + NOPRIOHOSTSRC= > > + NOPRIOHOSTDST= > > + NOPRIOPORTSRC= > > + NOPRIOPORTDST= > > + '[' stop = status ']' > > + tc qdisc del dev eth0 root > > + tc qdisc del dev eth0 ingress > > + '[' stop = stop ']' > > + exit > > > > root@Devil :~ # > > > > Don't think we generated enough uplink traffic to exercise the htb qdiscs. > > > > But it doesn't look like the ingress qdisc is working at all. > > > > I'm out of ideas for now. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) > > iD4DBQFFYiJDJ62kxkSCtLARAoCSAJiAi9VWPPNxy2q7NkH+pTvhSptbAJ930j0z > KS/+8xz2JoVcSDm8taaDIA== > =Jphi > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Devil-linux-discuss mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss > -- Drew Einhorn |
|
From: Kari M. <kar...@tr...> - 2006-11-20 22:44:19
|
drew einhorn wrote: > Hmm. Has there been any consideration to moving DL to a 2.6 kernel? > As time goes by it's just going to get harder and harder to backport and > maintain applications to run on a 2.4 kernel. I leave this to Heiko and others. > I believe tcng is a higher level language that generates shell scripts > calling the tc commands, etc. > > But I need to take a closer look at it. Well, it is just that. A kind of wrapper. BandwidthArbitrator is quite the same + Qos, GUI, reporting, etc. The command 'tc' the actual, real thing. That does the job. > I'll let you know if I decide to take a close look at Bandwidth Aggregator. > > Want to look for an easier solution to the problem first. Maybe the easiest start is to only limit outgoing traffic. That works. Add VLANs and incoming traffic shaping after that. > Thanks, > > Drew |
|
From: drew e. <dre...@gm...> - 2006-11-20 22:30:42
|
SG1tLiAgSGFzIHRoZXJlIGJlZW4gYW55IGNvbnNpZGVyYXRpb24gdG8gbW92aW5nIERMIHRvIGEg Mi42IGtlcm5lbD8KQXMgdGltZSBnb2VzIGJ5IGl0J3MganVzdCBnb2luZyB0byBnZXQgaGFyZGVy IGFuZCBoYXJkZXIgdG8gYmFja3BvcnQgYW5kCm1haW50YWluIGFwcGxpY2F0aW9ucyB0byBydW4g b24gYSAyLjQga2VybmVsLgoKSSBiZWxpZXZlIHRjbmcgaXMgYSBoaWdoZXIgbGV2ZWwgbGFuZ3Vh Z2UgdGhhdCBnZW5lcmF0ZXMgc2hlbGwgc2NyaXB0cwpjYWxsaW5nIHRoZSB0YyBjb21tYW5kcywg ZXRjLgoKQnV0IEkgbmVlZCB0byB0YWtlIGEgY2xvc2VyIGxvb2sgYXQgaXQuCgpJJ2xsIGxldCB5 b3Uga25vdyBpZiBJIGRlY2lkZSB0byB0YWtlIGEgY2xvc2UgbG9vayBhdCBCYW5kd2lkdGggQWdn cmVnYXRvci4KCldhbnQgdG8gbG9vayBmb3IgYW4gZWFzaWVyIHNvbHV0aW9uIHRvIHRoZSBwcm9i bGVtIGZpcnN0LgoKVGhhbmtzLAoKRHJldwoKT24gMTEvMjAvMDYsIERyLiBBbGJlcnRvIEJlbmF0 aSA8YmVuYXRpQGVjb25vbWlhLnVuaWZlLml0PiB3cm90ZToKPiBJIGhhdmUgYSB3b3JraW5nIHZl cnNpb24gb2YgYXJiaXRyYXRvciBpbiBEZXZpbC1MaW51eCAoaW4gcHJvZHVjdGlvbiBzZXJ2ZXIh KVNlbnQ6IE1vbiwgMjAgTm92IDIwMDYgMTQ6NDY6NDMgLTA3MDAKU3ViamVjdDogUmU6IFtEZXZp bC1MaW51eC1kaXNjdXNzXSBGd2Q6IFRyYWZmaWMgU2hhcGluZyBvbiBhIFRyYW5zcGFyZW50CkJy aWRnZSBub3Qgd29ya2luZyEKCj4gLS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQo+ IEhhc2g6IFNIQTEKPgo+IE5vdCBzdXJlIGlmIGl0IGhlbHBzLCBidXQgeW91IG1heSBhbHNvIHdh bnQgdG8gbG9vayBhdCBiYW5kd2lkdGggYXJiaXRyYXRvcjoKPgo+IGh0dHA6Ly93d3cuYmFuZHdp ZHRoYXJiaXRyYXRvci5jb20vCj4KPiBJdCBkb2VzIHJlcXVpcmUgYSBwYXRjaGVkIGtlcm5lbCBz byB5b3Ugd291bGQgaGF2ZSB0byBkbyBhIGRldmlsLQo+IGxpbnV4IGNvbXBpbGF0aW9uLiAgSSBo YWQgYmVlbiBwbGFubmluZyB0byB0cnkgaXQgb24gRGV2aWwsIGp1c3QgaGF2ZW4ndAo+IGdvdHRl biBhcm91bmQgdG8gaXQgeWV0Lgo+Cj4gLSAtIGNhbWVyb24KPgo+IGRyZXcgZWluaG9ybiB3cm90 ZToKPiA+IFRyeWluZyBhZ2Fpbi4gIEhvcGUgSSdtIGZpbmFsbHkgb2ZmIHRoZSBib2d1cyBlbWFp bCBibGFja2xpc3QsIGFuZAo+ID4gdGhpcyBnb2VzIHRocm91Z2guCj4gPgo+ID4gLS0tLS0tLS0t LSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tCj4gPiBGcm9tOiBkcmV3IGVpbmhvcm4gPGRy ZXcuZWluaG9ybkBnbWFpbC5jb20+Cj4gPiBEYXRlOiBOb3YgMTksIDIwMDYgMTE6NTEgUE0KPiA+ IFN1YmplY3Q6IFRyYWZmaWMgU2hhcGluZyBvbiBhIFRyYW5zcGFyZW50IEJyaWRnZSBub3Qgd29y a2luZyEKPiA+IFRvOiBkZXZpbC1saW51eC1kaXNjdXNzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAo+ ID4KPiA+Cj4gPiBNeSBmaXJzdCBETCBwcm9qZWN0IHdhcyBnb2luZyB3ZWxsLiAgVGhlbiBJIHJh biBpbnRvIHByb2JsZW1zIGF0dGVtcHRpbmcKPiA+IHRvIHNoYXBlIG15IGJhbmR3aWR0aC4KPiA+ Cj4gPiBGaXJzdCBJJ2xsIGRlc2NyaWJlIHRoZSBwYXJ0cyB0aGF0IEkgYmVsaWV2ZSBhcmUgd29y a2luZyBjb3JyZWN0bHkuCj4gPgo+ID4gSSBoYXZlIGEgREwgMS4yLjExIGJveCBydW5uaW5nIHRo ZSBkZWZhdWx0IGtlcm5lbCwgMi40LjMzLjMtZ3JzZWMKPiA+Cj4gPiBJIGhhdmUgYnIwIGJyaWRn aW5nIGFsbCBmb3VyIHBvcnRzIGV0aDAsIGV0aDEsIGV0aDIsIGV0aDMgb24gYSBxdWFkIHBvcnQK PiA+IHBjaSBjYXJkLiAgVGhlIGJyaWRnZSBoYXMgbm90IGJlZW4gYXNzaWduZWQgYW4gaXAgbnVt YmVyIG9uIHRoZSB0aGVvcnkKPiA+IHRoYXQgdGhpcyBtYWtlcyBpdCBtdWNoIG1vcmUgZGlmZmlj dWx0IHRvIGF0dGFjay4gIFRoZSBicmlkZ2UgY29ubmVjdHMKPiA+IGZvdXIgZGV2aWNlcyBvbiB0 aGUgM2JpdCBwdWJsaWMgc3RhdGljIGlwIGJsb2NrIGZyb20gbXkgSVNQLgo+ID4KPiA+IEkgaGF2 ZSBhIHNpbmdsZSBwb3J0IGV0aGVybmV0IHBjaSBjYXJkLCBldGg0IHdpdGggYSBzdGF0aWMgaXAs IG9uIG15Cj4gPiBpbnRlcm5hbCBwcml2YXRlIGlwIG5ldHdvcmsuICBJdCBpcyB1c2VkIGZvciBy ZW1vdGUgbWFuYWdlbnQgb2YgdGhlIERMCj4gPiBib3ggZnJvbSBhbnl3aGVyZSBvbiBteSBpbnRl cm5hbCBuZXR3b3JrLgo+ID4KPiA+IGV0aDAgaXMgY29ubmVjdGVkIHRvIG15IElTUCdzIHJvdXRl ciB2aWEgdGhlIGV0aGVybmV0IHBvcnQgb24gbXkKPiA+IElTRE4gbW9kZW0uICBJIGtub3cgSVNE TiBpcyBhIG5lYXJseSBkZWFkIHRlY2hub2xvZ3ksIGJ1dCBpdCdzIHRoZSBiZXN0Cj4gPiB0aGlu ZyBteSBjcmFwcHkgdGVsY28gb2ZmZXJzLiAgVHJpZWQgYSBzYXRlbGxpdGUgSVNQLCBidXQgdGhh dCdzIGFub3RoZXIKPiA+IGxvbmcgc3RvcnkuCj4gPgo+ID4gZXRoMSBpcyBjb25uZWN0ZWQgdG8g YSBoYXJkZW5lZCBwdWJsaWNseSBhY2Nlc3NpYmxlIGhvc3QuCj4gPgo+ID4gZXRoMiBhbmQgZXRo MyBhcmUgY29ubmVjdGVkIHRvIHRoZSBXQU4gcG9ydHMgb24gYSBjb3VwbGUgb2YgTGlua3N5cwo+ ID4gQ2FibGUvRFNMIHJvdXRlcnMuICBFdmVudHVhbGx5IG1vc3Qgb2YgdGhlaXIgZnVuY3Rpb25z IHdpbGwgbWlncmF0ZSB0byB0aGUKPiA+IERMIGJveCwgYnV0IHRoYXQgaXMgbW9yZSB0aGFuIEkg d2FudGVkIHRvIGJpdGUgb2ZmIGluIG15IGZpcnN0IERMIHByb2plY3QuCj4gPgo+ID4gVGhlIGZp cnN0IExpbmtzeXMgYm94IE5BVHMgb25lIG9mIG15IHB1YmxpYyBpcHMgdG8gbXkgaW50ZXJuYWwg cHJpdmF0ZQo+ID4gaXAgbmV0d29yay4gIFRoZSBzZWNvbmQgTGlua3N5cyBib3ggaXMgbmV3ZXIg YW5kIGluY2x1ZGVzIGEgd2lyZWxlc3MKPiA+IGFjY2VzcyBwb2ludCB1c2VkIGJ5IGEgY291cGxl IG5laWdoYm9ycy4gIEl0IE5BVHMgYSBzZWNvbmQgcHVibGljIGlwIHRvCj4gPiBhIHNlcGFyYXRl IHByaXZhdGUgaXAgbmV0d29yay4KPiA+Cj4gPiBBbGwgb2YgdGhlIGFib3ZlIGFwcGVhcnMgdG8g YmUgd29ya2luZyBhcyBleHBlY3RlZC4KPiA+Cj4gPiBBZnRlciBwb25kZXJpbmcgdGhlIG15c3Rl cmllcyBvZiB0cmFmZmljIHNoYXBpbmcgSSBkZWNpZGVkIHRvIHN0YXJ0IHdpdGgKPiA+IHdvbmRl cnNoYXBlciAxLjFhIGZyb20gbGFydGMub3JnLCByYXRoZXIgdGhhbiBzdGFydGluZyBmcm9tIHNj cmF0Y2guCj4gPgo+ID4gVHJpZWQgYm90aCB0aGUgY2JxIGFuZCBodGIgdmVyc2lvbnMgd2l0aG91 dCBhbnkgc3VjY2Vzcy4KPiA+Cj4gPiBSVEZNIHRpbWUuICBUaGUgaHRiIHNlY3Rpb24gb2YgaHR0 cDovL2xhcnRjLm9yZy9ob3d0by9pbmRleC5odG1sIGlzIGVhc2llcgo+ID4gcmVhZGluZyB0aGFu IHRoZSBjYnEgc2VjdGlvbi4gIEFuZCB0aGUgaG93dG8gY2xhaW1zIGh0YiBpcyBiZXR0ZXIgYW55 d2F5Lgo+ID4gTGV0J3MgZm9jdXMgb24gdGhlIGh0YiB2ZXJzaW9uIG9mIHdvbmRlcnNoYXBlci4K PiA+Cj4gPiBPSywgRmlyc3Qgd2UgZWRpdCB3c2hhcGVyLmh0YiBhbmQgY29uZmlndXJlIHRoZSBz aGVsbCB2YXJpYWJsZXMuICBUaGVuIHdlCj4gPiBydW46ICBzaCAteCB3c2hhcGVyLmh0Ygo+ID4g dG8gZWNobyB0aGUgY29tbWFuZHMgYXMgdGhleSBhcmUgZXhlY3V0ZWQuCj4gPgo+ID4gVGhlbiB3 ZSBzdGFydCBwaW5naW5nIHRoZSByb3V0ZXIgYXQgdGhlIG90aGVyIGVuZCBvZiB0aGUgSVNETiBs aW5lLgo+ID4KPiA+IFRoZW4gd2Ugc3RhcnQgZG93bmxvYWRpbmcgYSBmaWxlIHRvIGdlbmVyYXRl IHNvbWUgdHJhZmZpYyB0aGF0IHJlYWxseQo+ID4gbmVlZHMgdG8gYmUgc2hhcGVkLgo+ID4KPiA+ IFRoZW4gd2UgcnVuOiBzaCAteCB3c2hhcGVyLmh0YiBzdGF0dXMKPiA+IHRvIGdhdGhlciBzb21l IHN0YXRpc3RpY3MKPiA+Cj4gPiB0aGVuIHdlIGtpbGwgdGhlIGRvd25sb2FkLgo+ID4KPiA+IHRo ZW4gd2Ugc2ggLXggd3NoYXBlci5odGIgc3RvcCB0byBzaHV0IGRvd24gdGhlIG1hbGZ1bmN0aW9u aW5nIHNoYXBlci4KPiA+Cj4gPiBIZXJlJ3MgdGhlIG91dHB1dCBmcm9tIHRoZSBwaW5nOgo+ID4K PiA+ICQgcGluZyA2Ny4wLjE5Mi4xMAo+ID4gUElORyA2Ny4wLjE5Mi4xMCAoNjcuMC4xOTIuMTAp IDU2KDg0KSBieXRlcyBvZiBkYXRhLgo+ID4KPiA+IExpbmsgaXMgaWRsZSwgbm9ybWFsIHBpbmcg dGltZXMuCj4gPgo+ID4gNjQgYnl0ZXMgZnJvbSA2Ny4wLjE5Mi4xMDogaWNtcF9zZXE9MCB0dGw9 MjU0IHRpbWU9NDguNSBtcwo+ID4gNjQgYnl0ZXMgZnJvbSA2Ny4wLjE5Mi4xMDogaWNtcF9zZXE9 MSB0dGw9MjU0IHRpbWU9NDguNCBtcwo+ID4gNjQgYnl0ZXMgZnJvbSA2Ny4wLjE5Mi4xMDogaWNt cF9zZXE9MiB0dGw9MjU0IHRpbWU9NDguNCBtcwo+ID4gNjQgYnl0ZXMgZnJvbSA2Ny4wLjE5Mi4x MDogaWNtcF9zZXE9MyB0dGw9MjU0IHRpbWU9NDguNCBtcwo+ID4gNjQgYnl0ZXMgZnJvbSA2Ny4w LjE5Mi4xMDogaWNtcF9zZXE9NCB0dGw9MjU0IHRpbWU9IDQ4LjUgbXMKPiA+IDY0IGJ5dGVzIGZy b20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTUgdHRsPTI1NCB0aW1lPTY3LjggbXMKPiA+IDY0IGJ5 dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTYgdHRsPTI1NCB0aW1lPTQ4LjMgbXMKPiA+ IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTcgdHRsPTI1NCB0aW1lPTQ4LjIg bXMKPiA+Cj4gPiBEb3dubG9hZCBzdGFydHMuICBTaGFwaW5nIGlzIG5vdCB3b3JraW5nISAgUXVl dWVzIGluCj4gPiByb3V0ZXIgYW5kL29yIElTRE4gbW9kZW0gZ3JvdywgYW5kIHBpbmcgdGltZXMg cmFwaWRseQo+ID4gYmVjb21lIGh1Z2UuCj4gPgo+ID4gNjQgYnl0ZXMgZnJvbSA2Ny4wLjE5Mi4x MDogaWNtcF9zZXE9OCB0dGw9MjU0IHRpbWU9MTg0IG1zCj4gPiA2NCBieXRlcyBmcm9tIDY3LjAu MTkyLjEwOiBpY21wX3NlcT05IHR0bD0yNTQgdGltZT0xMDgwIG1zCj4gPiA2NCBieXRlcyBmcm9t IDY3LjAuMTkyLjEwOiBpY21wX3NlcT0xMCB0dGw9MjU0IHRpbWU9MjAyNSBtcwo+ID4gNjQgYnl0 ZXMgZnJvbSA2Ny4wLjE5Mi4xMDogaWNtcF9zZXE9MTEgdHRsPTI1NCB0aW1lPTE1NTEgbXMKPiA+ IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTEyIHR0bD0yNTQgdGltZT0xMDc4 IG1zCj4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT0xMyB0dGw9MjU0IHRp bWU9ODk2IG1zCj4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT0xNCB0dGw9 MjU0IHRpbWU9MTA4OCBtcwo+ID4gNjQgYnl0ZXMgZnJvbSA2Ny4wLjE5Mi4xMDogaWNtcF9zZXE9 MTUgdHRsPTI1NCB0aW1lPTExNzEgbXMKPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGlj bXBfc2VxPTE2IHR0bD0yNTQgdGltZT0xMjcyIG1zCj4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTky LjEwOiBpY21wX3NlcT0xNyB0dGw9MjU0IHRpbWU9MTI4MCBtcwo+ID4gNjQgYnl0ZXMgZnJvbSA2 Ny4wLjE5Mi4xMDogaWNtcF9zZXE9MTggdHRsPTI1NCB0aW1lPTExMDEgbXMKPiA+IDY0IGJ5dGVz IGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTE5IHR0bD0yNTQgdGltZT0xMjU4IG1zCj4gPiA2 NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT0yMCB0dGw9MjU0IHRpbWU9MTIxMSBt cwo+ID4gNjQgYnl0ZXMgZnJvbSA2Ny4wLjE5Mi4xMDogaWNtcF9zZXE9MjEgdHRsPTI1NCB0aW1l PTEyNTkgbXMKPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTIyIHR0bD0y NTQgdGltZT0xMzczIG1zCj4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT0y MyB0dGw9MjU0IHRpbWU9MTQyNCBtcwo+ID4gNjQgYnl0ZXMgZnJvbSA2Ny4wLjE5Mi4xMDogaWNt cF9zZXE9MjQgdHRsPTI1NCB0aW1lPTE0NjEgbXMKPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIu MTA6IGljbXBfc2VxPTI1IHR0bD0yNTQgdGltZT0xMjc3IG1zCj4gPiA2NCBieXRlcyBmcm9tIDY3 LjAuMTkyLjEwOiBpY21wX3NlcT0yNiB0dGw9MjU0IHRpbWU9MTUyMSBtcwo+ID4gNjQgYnl0ZXMg ZnJvbSA2Ny4wLjE5Mi4xMDogaWNtcF9zZXE9MjcgdHRsPTI1NCB0aW1lPTE0NjcgbXMKPiA+IDY0 IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTI4IHR0bD0yNTQgdGltZT0xMzM1IG1z Cj4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT0yOSB0dGw9MjU0IHRpbWU9 MTMyOSBtcwo+ID4gNjQgYnl0ZXMgZnJvbSA2Ny4wLjE5Mi4xMDogaWNtcF9zZXE9MzAgdHRsPTI1 NCB0aW1lPTEzODYgbXMKPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTMx IHR0bD0yNTQgdGltZT0xMzYwIG1zCj4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBpY21w X3NlcT0zMiB0dGw9MjU0IHRpbWU9MTQxNiBtcwo+ID4gNjQgYnl0ZXMgZnJvbSA2Ny4wLjE5Mi4x MDogaWNtcF9zZXE9MzMgdHRsPTI1NCB0aW1lPTE0ODAgbXMKPiA+IDY0IGJ5dGVzIGZyb20gNjcu MC4xOTIuMTA6IGljbXBfc2VxPTM0IHR0bD0yNTQgdGltZT0xMzQ1IG1zCj4gPiA2NCBieXRlcyBm cm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT0zNSB0dGw9MjU0IHRpbWU9MTM1NiBtcwo+ID4gNjQg Ynl0ZXMgZnJvbSA2Ny4wLjE5Mi4xMDogaWNtcF9zZXE9MzYgdHRsPTI1NCB0aW1lPTEzNzAgbXMK PiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTM3IHR0bD0yNTQgdGltZT0x Mjc4IG1zCj4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT0zOCB0dGw9MjU0 IHRpbWU9MTYxMiBtcwo+ID4gNjQgYnl0ZXMgZnJvbSA2Ny4wLjE5Mi4xMDogaWNtcF9zZXE9Mzkg dHRsPTI1NCB0aW1lPTE1MjAgbXMKPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBf c2VxPTQwIHR0bD0yNTQgdGltZT0xMzIyIG1zCj4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEw OiBpY21wX3NlcT00MSB0dGw9MjU0IHRpbWU9MTU0NSBtcwo+ID4KPiA+IEtpbGwgdGhlIGRvd25s b2FkIHF1ZXVlcyBlbXB0eSBhbmQgcGluZyB0aW1lcyByZXR1cm4gdG8gbm9ybWFsCj4gPgo+ID4g NjQgYnl0ZXMgZnJvbSA2Ny4wLjE5Mi4xMCA6IGljbXBfc2VxPTQyIHR0bD0yNTQgdGltZT05NzUg bXMKPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTQzIHR0bD0yNTQgdGlt ZT02Ny40IG1zCj4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT00NCB0dGw9 MjU0IHRpbWU9IDczLjYgbXMKPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2Vx PTQ1IHR0bD0yNTQgdGltZT00NS4yIG1zCj4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBp Y21wX3NlcT00NiB0dGw9MjU0IHRpbWU9NDUuMiBtcwo+ID4gNjQgYnl0ZXMgZnJvbSA2Ny4wLjE5 Mi4xMDogaWNtcF9zZXE9NDcgdHRsPTI1NCB0aW1lPTQ0LjggbXMKPiA+Cj4gPgo+ID4gQW5kLCBo ZXJlJ3MgdGhlIHNoZWxsIGNvbW1hbmRzIGFuZCB0aGVpciBvdXRwdXQ6Cj4gPgo+ID4gcm9vdEBE ZXZpbDp+ICMgc2ggLXggd3NoYXBlci5odGIKPiA+ICsgRE9XTkxJTks9MTAwCj4gPiArIFVQTElO Sz0xMDAKPiA+ICsgREVWPWV0aDAKPiA+ICsgTk9QUklPSE9TVFNSQz0KPiA+ICArIE5PUFJJT0hP U1REU1Q9Cj4gPiArIE5PUFJJT1BPUlRTUkM9Cj4gPiArIE5PUFJJT1BPUlREU1Q9Cj4gPiArICdb JyAnJyA9IHN0YXR1cyAnXScKPiA+ICsgdGMgcWRpc2MgZGVsIGRldiBldGgwIHJvb3QKPiA+ICsg dGMgcWRpc2MgZGVsIGRldiBldGgwIGluZ3Jlc3MKPiA+ICsgJ1snICcnID0gc3RvcCAnXScKPiA+ ICsgdGMgcWRpc2MgYWRkIGRldiBldGgwIHJvb3QgaGFuZGxlIDE6IGh0YiBkZWZhdWx0IDIwCj4g PiArIHRjIGNsYXNzIGFkZCBkZXYgZXRoMCBwYXJlbnQgMTogY2xhc3NpZCAxOjEgaHRiIHJhdGUg MTAwa2JpdCBidXJzdCA2awo+ID4gKyB0YyBjbGFzcyBhZGQgZGV2IGV0aDAgcGFyZW50IDE6MSBj bGFzc2lkIDE6MTAgaHRiIHJhdGUgMTAwa2JpdCBidXJzdCA2awpwcmlvIDEKPiA+ICsgdGMgY2xh c3MgYWRkIGRldiBldGgwIHBhcmVudCAxOjEgY2xhc3NpZCAxOjIwIGh0YiByYXRlIDkwa2JpdCBi dXJzdCA2awpwcmlvIDIKPiA+ICsgdGMgY2xhc3MgYWRkIGRldiBldGgwIHBhcmVudCAxOjEgY2xh c3NpZCAxOjMwIGh0YiByYXRlIDgwa2JpdCBidXJzdCA2awpwcmlvIDIKPiA+ICsgdGMgcWRpc2Mg YWRkIGRldiBldGgwIHBhcmVudCAxOjEwIGhhbmRsZSAxMDogc2ZxIHBlcnR1cmIgMTAKPiA+ICsg dGMgcWRpc2MgYWRkIGRldiBldGgwIHBhcmVudCAxOjIwIGhhbmRsZSAyMDogc2ZxIHBlcnR1cmIg MTAKPiA+ICsgdGMgcWRpc2MgYWRkIGRldiBldGgwIHBhcmVudCAxOjMwIGhhbmRsZSAzMDogc2Zx IHBlcnR1cmIgMTAKPiA+ICsgdGMgZmlsdGVyIGFkZCBkZXYgZXRoMCBwYXJlbnQgMTowIHByb3Rv Y29sIGlwIHByaW8gMTAgdTMyIG1hdGNoIGlwCj4gPiB0b3MgMHgxMCAweGZmIGZsb3dpZCAxOjEw Cj4gPiArIHRjIGZpbHRlciBhZGQgZGV2IGV0aDAgcGFyZW50IDE6MCBwcm90b2NvbCBpcCBwcmlv IDEwIHUzMiBtYXRjaCBpcAo+ID4gcHJvdG9jb2wgMSAweGZmIGZsb3dpZCAxOjEwCj4gPiArIHRj IGZpbHRlciBhZGQgZGV2IGV0aDAgcGFyZW50IDE6IHByb3RvY29sIGlwIHByaW8gMTAgdTMyIG1h dGNoIGlwCj4gPiBwcm90b2NvbCA2IDB4ZmYgbWF0Y2ggdTggMHgwNSAweDBmIGF0IDAgbWF0Y2gg dTE2IDB4MDAwMCAweGZmYzAgYXQgMgo+ID4gbWF0Y2ggdTggMHgxMCAweGZmIGF0IDMzIGZsb3dp ZCAxOjEwCj4gPiArIHRjIGZpbHRlciBhZGQgZGV2IGV0aDAgcGFyZW50IDE6IHByb3RvY29sIGlw IHByaW8gMTggdTMyIG1hdGNoIGlwCj4gPiBkc3QgMC4wLjAuMC8wIGZsb3dpZCAxOjIwCj4gPiAr IHRjIHFkaXNjIGFkZCBkZXYgZXRoMCBoYW5kbGUgZmZmZjogaW5ncmVzcwo+ID4gKyB0YyBmaWx0 ZXIgYWRkIGRldiBldGgwIHBhcmVudCBmZmZmOiBwcm90b2NvbCBpcCBwcmlvIDUwIHUzMiBtYXRj aCBpcAo+ID4gc3JjIDAuMC4wLjAvMCBwb2xpY2UgcmF0ZSAxMDBrYml0IGJ1cnN0IDEwayBkcm9w IGZsb3dpZCA6MQo+ID4KPiA+Cj4gPiByb290QERldmlsOn4gIyBzaCAteCB3c2hhcGVyLmh0YiBz dGF0dXMKPiA+ICsgRE9XTkxJTks9MTAwCj4gPiArIFVQTElOSz0xMDAKPiA+ICsgREVWPWV0aDAK PiA+ICsgTk9QUklPSE9TVFNSQz0KPiA+ICsgTk9QUklPSE9TVERTVD0KPiA+ICsgTk9QUklPUE9S VFNSQz0KPiA+ICsgTk9QUklPUE9SVERTVD0KPiA+ICsgJ1snIHN0YXR1cyA9IHN0YXR1cyAnXScK PiA+ICsgdGMgLXMgcWRpc2MgbHMgZGV2IGV0aDAKPiA+IHFkaXNjIGh0YiAxOiByMnEgMTAgZGVm YXVsdCAyMCBkaXJlY3RfcGFja2V0c19zdGF0IDAKPiA+ICBTZW50IDE4NjQ5IGJ5dGVzIDE5MSBw a3RzIChkcm9wcGVkIDAsIG92ZXJsaW1pdHMgMCkKPiA+IHFkaXNjIHNmcSAxMDogcGFyZW50IDE6 MTAgbGltaXQgMTI4cCBxdWFudHVtIDE1MTRiIHBlcnR1cmIgMTBzZWMKPiA+ICBTZW50IDEwNTgy IGJ5dGVzIDE0NyBwa3RzIChkcm9wcGVkIDAsIG92ZXJsaW1pdHMgMCkKPiA+IHFkaXNjIHNmcSAy MDogcGFyZW50IDE6MjAgbGltaXQgMTI4cCBxdWFudHVtIDE1MTRiIHBlcnR1cmIgMTBzZWMKPiA+ ICBTZW50IDgwNjcgYnl0ZXMgNDQgcGt0cyAoZHJvcHBlZCAwLCBvdmVybGltaXRzIDApCj4gPiBx ZGlzYyBzZnEgMzA6IHBhcmVudCAxOjMwIGxpbWl0IDEyOHAgcXVhbnR1bSAxNTE0YiBwZXJ0dXJi IDEwc2VjCj4gPiAgU2VudCAwIGJ5dGVzIDAgcGt0cyAoZHJvcHBlZCAwLCBvdmVybGltaXRzIDAp Cj4gPiBxZGlzYyBpbmdyZXNzIGZmZmY6IC0tLS0tLS0tLS0tLS0tLS0KPiA+ICBTZW50IDAgYnl0 ZXMgMCBwa3RzIChkcm9wcGVkIDAsIG92ZXJsaW1pdHMgMCkKPiA+ICsgdGMgLXMgY2xhc3MgbHMg ZGV2IGV0aDAKPiA+IGNsYXNzIGh0YiAxOjEgcm9vdCByYXRlIDEwMDAwMGJpdCBjZWlsIDEwMDAw MGJpdCBidXJzdCA2S2IgY2J1cnN0IDE3MjRiCj4gPiAgU2VudCAxODY0OSBieXRlcyAxOTEgcGt0 cyAoZHJvcHBlZCAwLCBvdmVybGltaXRzIDApCj4gPiAgcmF0ZSAxMzIwYml0IDFwcHMKPiA+ICBs ZW5kZWQ6IDAgYm9ycm93ZWQ6IDAgZ2lhbnRzOiAwCj4gPiAgdG9rZW5zOiAzOTg0NTkgY3Rva2Vu czogMTA4ODU1Cj4gPgo+ID4gY2xhc3MgaHRiIDE6MTAgcGFyZW50IDE6MSBsZWFmIDEwOiBwcmlv IDEgcmF0ZSAxMDAwMDBiaXQgY2VpbAo+ID4gMTAwMDAwYml0IGJ1cnN0IDZLYiBjYnVyc3QgMTcy NGIKPiA+ICBTZW50IDEwNTgyIGJ5dGVzIDE0NyBwa3RzIChkcm9wcGVkIDAsIG92ZXJsaW1pdHMg MCkKPiA+ICByYXRlIDY1NmJpdCAxcHBzCj4gPiAgbGVuZGVkOiAxNDcgYm9ycm93ZWQ6IDAgZ2lh bnRzOiAwCj4gPiAgdG9rZW5zOiAzOTg0NTkgY3Rva2VuczogMTA4ODU1Cj4gPgo+ID4gY2xhc3Mg aHRiIDE6MjAgcGFyZW50IDE6MSBsZWFmIDIwOiBwcmlvIDIgcmF0ZSA5MDAwMGJpdCBjZWlsIDkw MDAwYml0Cj4gPiBidXJzdCA2S2IgY2J1cnN0IDE3MTFiCj4gPiAgU2VudCA4MDY3IGJ5dGVzIDQ0 IHBrdHMgKGRyb3BwZWQgMCwgb3ZlcmxpbWl0cyAwKQo+ID4gIHJhdGUgNzEyYml0Cj4gPiAgbGVu ZGVkOiA0NCBib3Jyb3dlZDogMCBnaWFudHM6IDAKPiA+ICB0b2tlbnM6IDQzMjI4NCBjdG9rZW5z OiAxMDk1NTUKPiA+Cj4gPiBjbGFzcyBodGIgMTozMCBwYXJlbnQgMToxIGxlYWYgMzA6IHByaW8g MiByYXRlIDgwMDAwYml0IGNlaWwgODAwMDBiaXQKPiA+IGJ1cnN0IDZLYiBjYnVyc3QgMTY5OWIK PiA+ICBTZW50IDAgYnl0ZXMgMCBwa3RzIChkcm9wcGVkIDAsIG92ZXJsaW1pdHMgMCkKPiA+ICBs ZW5kZWQ6IDAgYm9ycm93ZWQ6IDAgZ2lhbnRzOiAwCj4gPiAgdG9rZW5zOiA1MDMzMTYgY3Rva2Vu czogMTM5MjY0Cj4gPgo+ID4gKyBleGl0Cj4gPiByb290QERldmlsOn4gIyBzaCAteCB3c2hhcGVy Lmh0YiBzdG9wCj4gPiArIERPV05MSU5LPTEwMAo+ID4gKyBVUExJTks9MTAwCj4gPiArIERFVj1l dGgwCj4gPiArIE5PUFJJT0hPU1RTUkM9Cj4gPiArIE5PUFJJT0hPU1REU1Q9Cj4gPiArIE5PUFJJ T1BPUlRTUkM9Cj4gPiArIE5PUFJJT1BPUlREU1Q9Cj4gPiArICdbJyBzdG9wID0gc3RhdHVzICdd Jwo+ID4gKyB0YyBxZGlzYyBkZWwgZGV2IGV0aDAgcm9vdAo+ID4gKyB0YyBxZGlzYyBkZWwgZGV2 IGV0aDAgaW5ncmVzcwo+ID4gKyAnWycgc3RvcCA9IHN0b3AgJ10nCj4gPiArIGV4aXQKPiA+Cj4g PiByb290QERldmlsIDp+ICMKPiA+Cj4gPiBEb24ndCB0aGluayB3ZSBnZW5lcmF0ZWQgZW5vdWdo IHVwbGluayB0cmFmZmljIHRvIGV4ZXJjaXNlIHRoZSBodGIgcWRpc2NzLgo+ID4KPiA+IEJ1dCBp dCBkb2Vzbid0IGxvb2sgbGlrZSB0aGUgaW5ncmVzcyBxZGlzYyBpcyB3b3JraW5nIGF0IGFsbC4K PiA+Cj4gPiBJJ20gb3V0IG9mIGlkZWFzIGZvciBub3cuCj4gPgo+IC0tLS0tQkVHSU4gUEdQIFNJ R05BVFVSRS0tLS0tCj4gVmVyc2lvbjogR251UEcgdjEuNC4yLjIgKEdOVS9MaW51eCkKPgo+IGlE NERCUUZGWWlKREo2Mmt4a1NDdExBUkFvQ1NBSmlBaTlWV1BQTnh5MnE3TmtIK3BUdmhTcHRiQUo5 MzBqMHoKPiBLUy8rOHh6MkpvVmNTRG04dGFhRElBPT0KPiA9SnBoaQo+IC0tLS0tRU5EIFBHUCBT SUdOQVRVUkUtLS0tLQo+Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IFRha2UgU3VydmV5cy4gRWFybiBD YXNoLiBJbmZsdWVuY2UgdGhlIEZ1dHVyZSBvZiBJVAo+IEpvaW4gU291cmNlRm9yZ2UubmV0J3Mg VGVjaHNheSBwYW5lbCBhbmQgeW91J2xsIGdldCB0aGUgY2hhbmNlIHRvCj4gc2hhcmUgeW91ciBv cGluaW9ucyBvbiBJVCAmIGJ1c2luZXNzIHRvcGljcyB0aHJvdWdoIGJyaWVmIHN1cnZleXMgLQo+ ICBhbmQgZWFybiBjYXNoCmh0dHA6Ly93d3cudGVjaHNheS5jb20vZGVmYXVsdC5waHA/cGFnZT1q b2luLnBocCZwPXNvdXJjZWZvcmdlJkNJRD1ERVZERVYKPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwo+IERldmlsLWxpbnV4LWRpc2N1c3MgbWFpbGluZyBs aXN0Cj4gRGV2aWwtbGludXgtZGlzY3Vzc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiBodHRwczov L2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9kZXZpbC1saW51eC1kaXNjdXNz Ci0tLS0tLS0gRW5kIG9mIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLQotIFNob3cgcXVvdGVkIHRl eHQgLQoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KVGFrZSBTdXJ2ZXlzLiBFYXJuIENhc2guIEluZmx1ZW5j ZSB0aGUgRnV0dXJlIG9mIElUCkpvaW4gU291cmNlRm9yZ2UubmV0J3MgVGVjaHNheSBwYW5lbCBh bmQgeW91J2xsIGdldCB0aGUgY2hhbmNlIHRvIHNoYXJlIHlvdXIKb3BpbmlvbnMgb24gSVQgJiBi dXNpbmVzcyB0b3BpY3MgdGhyb3VnaCBicmllZiBzdXJ2ZXlzIC0gYW5kIGVhcm4gY2FzaApodHRw Oi8vd3d3LnRlY2hzYXkuY29tL2RlZmF1bHQucGhwP3BhZ2U9am9pbi5waHAmcD1zb3VyY2Vmb3Jn ZSZDSUQ9REVWREVWCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCkRldmlsLWxpbnV4LWRpc2N1c3MgbWFpbGluZyBsaXN0CkRldmlsLWxpbnV4LWRpc2N1c3NA bGlzdHMuc291cmNlZm9yZ2UubmV0Cmh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3Rz L2xpc3RpbmZvL2RldmlsLWxpbnV4LWRpc2N1c3MKCgkKUmVwbHkJRm9yd2FyZAlJbnZpdGUgQWxi ZXJ0byB0byBHbWFpbAoJCgkKU2VuZCAgU2F2ZSBOb3cgIERpc2NhcmQKCQpGcm9tOgkKRnJvbToJ ZHJldyBlaW5ob3JuIDxkcmV3LmVpbmhvcm5AZ21haWwuY29tPiAgY2hhbmdlClRvOglkZXZpbC1s aW51eC1kaXNjdXNzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldApDYzoJCkJjYzoJCiAJCkFkZCBDYyB8 IEFkZCBCY2MgfCBFZGl0IFN1YmplY3QgfCBBdHRhY2ggYSBmaWxlCQpTdWJqZWN0OgkKCQpBdHRh Y2ggYSBmaWxlCgkKIyAgQ2hvb3NlIExhbmd1YWdlCiMgICBBdXRvCiMgICBFbmdsaXNoIChVUykK IyAgIEVuZ2xpc2ggKFVLKQojICAgRGV1dHNjaAojICAgRXNwYcOxb2wKIyAgIFBvcnR1Z3XDqnMK IyAgIFBvcnR1Z3XDqnMgKFBvcnR1Z2FsKQojICAgRnJhbsOnYWlzCiMgICBJdGFsaWFubwojICAg TmVkZXJsYW5kcwojICAgUG9sc2tpCiMgICBTdmVuc2thCiMgICBOb3JzawojICAgU3VvbWkKIyAg IERhbnNrCiMgICDQkdGK0LvQs9Cw0YDRgdC60LgKIyAgIEhydmF0c2tpCiMgICBNYWd5YXIKIyAg IFNsb3ZlbnNrw70KIyAgIFNsb3ZlbsWhxI1pbmEKIyAgINCj0LrRgNCw0ZfQvdGB0YzQutCwCiMg ICBUaeG6v25nIFZp4buHdAojICAgzpXOu867zrfOvc65zrrOrAojICAgw41zbGVuc2thCiMgICBC YWhhc2EgSW5kb25lc2lhCiMgICBDYXRhbMOgCiMgICDEjGVza8O9CiMgICBFZXN0aSBrZWVsCiMg ICDgpLngpL/gpKjgpY3gpKbgpYAKIyAgIExpZXR1dmnFswojICAgUm9tw6JuxIMKIyAgINCg0YPR gdGB0LrQuNC5CiMgICBUYWdhbG9nCiMgICBMYXRpbgojICAgSGVicmV3CgkKQ2hlY2sgc3BlbGxp bmcgIC0gRG9uZQogUmljaCBmb3JtYXR0aW5nIMK7CiwKPiBidXQgaXQncyB2ZXJ5IGRpZmZpY3Vs dCBtYW50YWluIHRoaXMgcHJvamVjdCAodHdvIHllYXJzIGFnbyBJIGJvdWdodCBhIHJwbQo+IHZl cnNpb24gZm9yIGtlcm5lbCAyLjQuMjEpIGJlY2F1c2UgdGhlIGtlcm5lbCBwYXRjaCBpdCdzIG5v dCB2ZXJ5IHdlbGwgYW5kIG5vdwo+IGxpdHRsZSBtYWludGFpbmVkIGZvciBHUEwgdmVyc2lvbi4K PiBJbiB3ZWJzaXRlIHRoZXJlIGlzIGEgbWluaWhvd3RvIGZvciAyLjQuMzAKPiAoaHR0cDovL3d3 dy5iYW5kd2lkdGhhcmJpdHJhdG9yLmNvbS9tb2R1bGVzLnBocD9uYW1lPU5ld3MmZmlsZT1hcnRp Y2xlJnNpZD0zMikKPiAgdGhhdCBpcyBhIHN5bnRoZXNpcyBvZiBqb2IgKG9uZSB5ZWFyIGFnbykg aW4gRGV2aWwtTGludXguCj4KPiBJZiB5b3UgdGhpbmsgaXQgY291bGQgYmUgb2YgaW50ZXJlc3Qs IEkgY291bGQgcHVibGlzaCBzY3JpcHRzIGFuZCBwYXRjaCBmb3IgMi40LjMzCj4KPiBUaGVyZSBp cyBhIHByb2plY3QgdGhhdCwgSSB0aGluaywgYW4gYWR2YW5jZWQgdHJhZmZpYyBzaGFwaW5nLCBz ZWUgeW86Cj4gaHR0cDovL3Rjbmcuc291cmNlZm9yZ2UubmV0Cj4gaHR0cDovL3RsZHAub3JnL0hP V1RPL1RyYWZmaWMtQ29udHJvbC10Y25nLUhUQi1IT1dUTwo+Cj4gVGhlcmUgYWx3YXlzIGxpdHRs ZSB0aW1lIC4uLgo+Cj4gUmVnYXJkcwo+IEFsYmVydG8KPgo+ICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsKPiB8ICAgRG90dC4gQWxiZXJ0byBCZW5hdGkgICB8Cj4gfCAgIFN5c3RlbSBBZG1p bmlzdHJhdG9yICAgfAo+IHwgICBGYWN1bHR5IG9mIEVjb25vbWljcyAgIHwKPiB8ICBVbml2ZXJz aXR5IG9mICBGZXJyYXJhICB8Cj4gfCBiZW5hdGlAZWNvbm9taWEudW5pZmUuaXQgfAo+IHwgIFRl bDogKzM5IDA1MzIgNDUgNTAxMiAgIHwKPiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCj4K Pgo+IC0tLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLS0tLQo+IEZyb206IGNkbWls bGVyIDxjZG1pbGxlckBhZGFtcy5lZHU+Cj4gVG86IGRldmlsLWxpbnV4LWRpc2N1c3NAbGlzdHMu c291cmNlZm9yZ2UubmV0Cj4gU2VudDogTW9uLCAyMCBOb3YgMjAwNiAxNDo0Njo0MyAtMDcwMAo+ IFN1YmplY3Q6IFJlOiBbRGV2aWwtTGludXgtZGlzY3Vzc10gRndkOiBUcmFmZmljIFNoYXBpbmcg b24gYSBUcmFuc3BhcmVudAo+IEJyaWRnZSBub3Qgd29ya2luZyEKPgo+ID4gLS0tLS1CRUdJTiBQ R1AgU0lHTkVEIE1FU1NBR0UtLS0tLQo+ID4gSGFzaDogU0hBMQo+ID4KPiA+IE5vdCBzdXJlIGlm IGl0IGhlbHBzLCBidXQgeW91IG1heSBhbHNvIHdhbnQgdG8gbG9vayBhdCBiYW5kd2lkdGggYXJi aXRyYXRvcjoKPiA+Cj4gPiBodHRwOi8vd3d3LmJhbmR3aWR0aGFyYml0cmF0b3IuY29tLwo+ID4K PiA+IEl0IGRvZXMgcmVxdWlyZSBhIHBhdGNoZWQga2VybmVsIHNvIHlvdSB3b3VsZCBoYXZlIHRv IGRvIGEgZGV2aWwtCj4gPiBsaW51eCBjb21waWxhdGlvbi4gIEkgaGFkIGJlZW4gcGxhbm5pbmcg dG8gdHJ5IGl0IG9uIERldmlsLCBqdXN0IGhhdmVuJ3QKPiA+IGdvdHRlbiBhcm91bmQgdG8gaXQg eWV0Lgo+ID4KPiA+IC0gLSBjYW1lcm9uCj4gPgo+ID4gZHJldyBlaW5ob3JuIHdyb3RlOgo+ID4g PiBUcnlpbmcgYWdhaW4uICBIb3BlIEknbSBmaW5hbGx5IG9mZiB0aGUgYm9ndXMgZW1haWwgYmxh Y2tsaXN0LCBhbmQKPiA+ID4gdGhpcyBnb2VzIHRocm91Z2guCj4gPiA+Cj4gPiA+IC0tLS0tLS0t LS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQo+ID4gPiBGcm9tOiBkcmV3IGVpbmhvcm4g PGRyZXcuZWluaG9ybkBnbWFpbC5jb20+Cj4gPiA+IERhdGU6IE5vdiAxOSwgMjAwNiAxMTo1MSBQ TQo+ID4gPiBTdWJqZWN0OiBUcmFmZmljIFNoYXBpbmcgb24gYSBUcmFuc3BhcmVudCBCcmlkZ2Ug bm90IHdvcmtpbmchCj4gPiA+IFRvOiBkZXZpbC1saW51eC1kaXNjdXNzQGxpc3RzLnNvdXJjZWZv cmdlLm5ldAo+ID4gPgo+ID4gPgo+ID4gPiBNeSBmaXJzdCBETCBwcm9qZWN0IHdhcyBnb2luZyB3 ZWxsLiAgVGhlbiBJIHJhbiBpbnRvIHByb2JsZW1zIGF0dGVtcHRpbmcKPiA+ID4gdG8gc2hhcGUg bXkgYmFuZHdpZHRoLgo+ID4gPgo+ID4gPiBGaXJzdCBJJ2xsIGRlc2NyaWJlIHRoZSBwYXJ0cyB0 aGF0IEkgYmVsaWV2ZSBhcmUgd29ya2luZyBjb3JyZWN0bHkuCj4gPiA+Cj4gPiA+IEkgaGF2ZSBh IERMIDEuMi4xMSBib3ggcnVubmluZyB0aGUgZGVmYXVsdCBrZXJuZWwsIDIuNC4zMy4zLWdyc2Vj Cj4gPiA+Cj4gPiA+IEkgaGF2ZSBicjAgYnJpZGdpbmcgYWxsIGZvdXIgcG9ydHMgZXRoMCwgZXRo MSwgZXRoMiwgZXRoMyBvbiBhIHF1YWQgcG9ydAo+ID4gPiBwY2kgY2FyZC4gIFRoZSBicmlkZ2Ug aGFzIG5vdCBiZWVuIGFzc2lnbmVkIGFuIGlwIG51bWJlciBvbiB0aGUgdGhlb3J5Cj4gPiA+IHRo YXQgdGhpcyBtYWtlcyBpdCBtdWNoIG1vcmUgZGlmZmljdWx0IHRvIGF0dGFjay4gIFRoZSBicmlk Z2UgY29ubmVjdHMKPiA+ID4gZm91ciBkZXZpY2VzIG9uIHRoZSAzYml0IHB1YmxpYyBzdGF0aWMg aXAgYmxvY2sgZnJvbSBteSBJU1AuCj4gPiA+Cj4gPiA+IEkgaGF2ZSBhIHNpbmdsZSBwb3J0IGV0 aGVybmV0IHBjaSBjYXJkLCBldGg0IHdpdGggYSBzdGF0aWMgaXAsIG9uIG15Cj4gPiA+IGludGVy bmFsIHByaXZhdGUgaXAgbmV0d29yay4gIEl0IGlzIHVzZWQgZm9yIHJlbW90ZSBtYW5hZ2VudCBv ZiB0aGUgREwKPiA+ID4gYm94IGZyb20gYW55d2hlcmUgb24gbXkgaW50ZXJuYWwgbmV0d29yay4K PiA+ID4KPiA+ID4gZXRoMCBpcyBjb25uZWN0ZWQgdG8gbXkgSVNQJ3Mgcm91dGVyIHZpYSB0aGUg ZXRoZXJuZXQgcG9ydCBvbiBteQo+ID4gPiBJU0ROIG1vZGVtLiAgSSBrbm93IElTRE4gaXMgYSBu ZWFybHkgZGVhZCB0ZWNobm9sb2d5LCBidXQgaXQncyB0aGUgYmVzdAo+ID4gPiB0aGluZyBteSBj cmFwcHkgdGVsY28gb2ZmZXJzLiAgVHJpZWQgYSBzYXRlbGxpdGUgSVNQLCBidXQgdGhhdCdzIGFu b3RoZXIKPiA+ID4gbG9uZyBzdG9yeS4KPiA+ID4KPiA+ID4gZXRoMSBpcyBjb25uZWN0ZWQgdG8g YSBoYXJkZW5lZCBwdWJsaWNseSBhY2Nlc3NpYmxlIGhvc3QuCj4gPiA+Cj4gPiA+IGV0aDIgYW5k IGV0aDMgYXJlIGNvbm5lY3RlZCB0byB0aGUgV0FOIHBvcnRzIG9uIGEgY291cGxlIG9mIExpbmtz eXMKPiA+ID4gQ2FibGUvRFNMIHJvdXRlcnMuICBFdmVudHVhbGx5IG1vc3Qgb2YgdGhlaXIgZnVu Y3Rpb25zIHdpbGwgbWlncmF0ZSB0byB0aGUKPiA+ID4gREwgYm94LCBidXQgdGhhdCBpcyBtb3Jl IHRoYW4gSSB3YW50ZWQgdG8gYml0ZSBvZmYgaW4gbXkgZmlyc3QgREwgcHJvamVjdC4KPiA+ID4K PiA+ID4gVGhlIGZpcnN0IExpbmtzeXMgYm94IE5BVHMgb25lIG9mIG15IHB1YmxpYyBpcHMgdG8g bXkgaW50ZXJuYWwgcHJpdmF0ZQo+ID4gPiBpcCBuZXR3b3JrLiAgVGhlIHNlY29uZCBMaW5rc3lz IGJveCBpcyBuZXdlciBhbmQgaW5jbHVkZXMgYSB3aXJlbGVzcwo+ID4gPiBhY2Nlc3MgcG9pbnQg dXNlZCBieSBhIGNvdXBsZSBuZWlnaGJvcnMuICBJdCBOQVRzIGEgc2Vjb25kIHB1YmxpYyBpcCB0 bwo+ID4gPiBhIHNlcGFyYXRlIHByaXZhdGUgaXAgbmV0d29yay4KPiA+ID4KPiA+ID4gQWxsIG9m IHRoZSBhYm92ZSBhcHBlYXJzIHRvIGJlIHdvcmtpbmcgYXMgZXhwZWN0ZWQuCj4gPiA+Cj4gPiA+ IEFmdGVyIHBvbmRlcmluZyB0aGUgbXlzdGVyaWVzIG9mIHRyYWZmaWMgc2hhcGluZyBJIGRlY2lk ZWQgdG8gc3RhcnQgd2l0aAo+ID4gPiB3b25kZXJzaGFwZXIgMS4xYSBmcm9tIGxhcnRjLm9yZywg cmF0aGVyIHRoYW4gc3RhcnRpbmcgZnJvbSBzY3JhdGNoLgo+ID4gPgo+ID4gPiBUcmllZCBib3Ro IHRoZSBjYnEgYW5kIGh0YiB2ZXJzaW9ucyB3aXRob3V0IGFueSBzdWNjZXNzLgo+ID4gPgo+ID4g PiBSVEZNIHRpbWUuICBUaGUgaHRiIHNlY3Rpb24gb2YgaHR0cDovL2xhcnRjLm9yZy9ob3d0by9p bmRleC5odG1sIGlzIGVhc2llcgo+ID4gPiByZWFkaW5nIHRoYW4gdGhlIGNicSBzZWN0aW9uLiAg QW5kIHRoZSBob3d0byBjbGFpbXMgaHRiIGlzIGJldHRlciBhbnl3YXkuCj4gPiA+IExldCdzIGZv Y3VzIG9uIHRoZSBodGIgdmVyc2lvbiBvZiB3b25kZXJzaGFwZXIuCj4gPiA+Cj4gPiA+IE9LLCBG aXJzdCB3ZSBlZGl0IHdzaGFwZXIuaHRiIGFuZCBjb25maWd1cmUgdGhlIHNoZWxsIHZhcmlhYmxl cy4gIFRoZW4gd2UKPiA+ID4gcnVuOiAgc2ggLXggd3NoYXBlci5odGIKPiA+ID4gdG8gZWNobyB0 aGUgY29tbWFuZHMgYXMgdGhleSBhcmUgZXhlY3V0ZWQuCj4gPiA+Cj4gPiA+IFRoZW4gd2Ugc3Rh cnQgcGluZ2luZyB0aGUgcm91dGVyIGF0IHRoZSBvdGhlciBlbmQgb2YgdGhlIElTRE4gbGluZS4K PiA+ID4KPiA+ID4gVGhlbiB3ZSBzdGFydCBkb3dubG9hZGluZyBhIGZpbGUgdG8gZ2VuZXJhdGUg c29tZSB0cmFmZmljIHRoYXQgcmVhbGx5Cj4gPiA+IG5lZWRzIHRvIGJlIHNoYXBlZC4KPiA+ID4K PiA+ID4gVGhlbiB3ZSBydW46IHNoIC14IHdzaGFwZXIuaHRiIHN0YXR1cwo+ID4gPiB0byBnYXRo ZXIgc29tZSBzdGF0aXN0aWNzCj4gPiA+Cj4gPiA+IHRoZW4gd2Uga2lsbCB0aGUgZG93bmxvYWQu Cj4gPiA+Cj4gPiA+IHRoZW4gd2Ugc2ggLXggd3NoYXBlci5odGIgc3RvcCB0byBzaHV0IGRvd24g dGhlIG1hbGZ1bmN0aW9uaW5nIHNoYXBlci4KPiA+ID4KPiA+ID4gSGVyZSdzIHRoZSBvdXRwdXQg ZnJvbSB0aGUgcGluZzoKPiA+ID4KPiA+ID4gJCBwaW5nIDY3LjAuMTkyLjEwCj4gPiA+IFBJTkcg NjcuMC4xOTIuMTAgKDY3LjAuMTkyLjEwKSA1Nig4NCkgYnl0ZXMgb2YgZGF0YS4KPiA+ID4KPiA+ ID4gTGluayBpcyBpZGxlLCBub3JtYWwgcGluZyB0aW1lcy4KPiA+ID4KPiA+ID4gNjQgYnl0ZXMg ZnJvbSA2Ny4wLjE5Mi4xMDogaWNtcF9zZXE9MCB0dGw9MjU0IHRpbWU9NDguNSBtcwo+ID4gPiA2 NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT0xIHR0bD0yNTQgdGltZT00OC40IG1z Cj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTIgdHRsPTI1NCB0aW1l PTQ4LjQgbXMKPiA+ID4gNjQgYnl0ZXMgZnJvbSA2Ny4wLjE5Mi4xMDogaWNtcF9zZXE9MyB0dGw9 MjU0IHRpbWU9NDguNCBtcwo+ID4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBpY21wX3Nl cT00IHR0bD0yNTQgdGltZT0gNDguNSBtcwo+ID4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEw OiBpY21wX3NlcT01IHR0bD0yNTQgdGltZT02Ny44IG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcu MC4xOTIuMTA6IGljbXBfc2VxPTYgdHRsPTI1NCB0aW1lPTQ4LjMgbXMKPiA+ID4gNjQgYnl0ZXMg ZnJvbSA2Ny4wLjE5Mi4xMDogaWNtcF9zZXE9NyB0dGw9MjU0IHRpbWU9NDguMiBtcwo+ID4gPgo+ ID4gPiBEb3dubG9hZCBzdGFydHMuICBTaGFwaW5nIGlzIG5vdCB3b3JraW5nISAgUXVldWVzIGlu Cj4gPiA+IHJvdXRlciBhbmQvb3IgSVNETiBtb2RlbSBncm93LCBhbmQgcGluZyB0aW1lcyByYXBp ZGx5Cj4gPiA+IGJlY29tZSBodWdlLgo+ID4gPgo+ID4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTky LjEwOiBpY21wX3NlcT04IHR0bD0yNTQgdGltZT0xODQgbXMKPiA+ID4gNjQgYnl0ZXMgZnJvbSA2 Ny4wLjE5Mi4xMDogaWNtcF9zZXE9OSB0dGw9MjU0IHRpbWU9MTA4MCBtcwo+ID4gPiA2NCBieXRl cyBmcm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT0xMCB0dGw9MjU0IHRpbWU9MjAyNSBtcwo+ID4g PiA2NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT0xMSB0dGw9MjU0IHRpbWU9MTU1 MSBtcwo+ID4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT0xMiB0dGw9MjU0 IHRpbWU9MTA3OCBtcwo+ID4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT0x MyB0dGw9MjU0IHRpbWU9ODk2IG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGlj bXBfc2VxPTE0IHR0bD0yNTQgdGltZT0xMDg4IG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4x OTIuMTA6IGljbXBfc2VxPTE1IHR0bD0yNTQgdGltZT0xMTcxIG1zCj4gPiA+IDY0IGJ5dGVzIGZy b20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTE2IHR0bD0yNTQgdGltZT0xMjcyIG1zCj4gPiA+IDY0 IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTE3IHR0bD0yNTQgdGltZT0xMjgwIG1z Cj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTE4IHR0bD0yNTQgdGlt ZT0xMTAxIG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTE5IHR0 bD0yNTQgdGltZT0xMjU4IG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBf c2VxPTIwIHR0bD0yNTQgdGltZT0xMjExIG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIu MTA6IGljbXBfc2VxPTIxIHR0bD0yNTQgdGltZT0xMjU5IG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20g NjcuMC4xOTIuMTA6IGljbXBfc2VxPTIyIHR0bD0yNTQgdGltZT0xMzczIG1zCj4gPiA+IDY0IGJ5 dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTIzIHR0bD0yNTQgdGltZT0xNDI0IG1zCj4g PiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTI0IHR0bD0yNTQgdGltZT0x NDYxIG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTI1IHR0bD0y NTQgdGltZT0xMjc3IG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2Vx PTI2IHR0bD0yNTQgdGltZT0xNTIxIG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6 IGljbXBfc2VxPTI3IHR0bD0yNTQgdGltZT0xNDY3IG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcu MC4xOTIuMTA6IGljbXBfc2VxPTI4IHR0bD0yNTQgdGltZT0xMzM1IG1zCj4gPiA+IDY0IGJ5dGVz IGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTI5IHR0bD0yNTQgdGltZT0xMzI5IG1zCj4gPiA+ IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTMwIHR0bD0yNTQgdGltZT0xMzg2 IG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTMxIHR0bD0yNTQg dGltZT0xMzYwIG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTMy IHR0bD0yNTQgdGltZT0xNDE2IG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGlj bXBfc2VxPTMzIHR0bD0yNTQgdGltZT0xNDgwIG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4x OTIuMTA6IGljbXBfc2VxPTM0IHR0bD0yNTQgdGltZT0xMzQ1IG1zCj4gPiA+IDY0IGJ5dGVzIGZy b20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTM1IHR0bD0yNTQgdGltZT0xMzU2IG1zCj4gPiA+IDY0 IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTM2IHR0bD0yNTQgdGltZT0xMzcwIG1z Cj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTM3IHR0bD0yNTQgdGlt ZT0xMjc4IG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBfc2VxPTM4IHR0 bD0yNTQgdGltZT0xNjEyIG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGljbXBf c2VxPTM5IHR0bD0yNTQgdGltZT0xNTIwIG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIu MTA6IGljbXBfc2VxPTQwIHR0bD0yNTQgdGltZT0xMzIyIG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20g NjcuMC4xOTIuMTA6IGljbXBfc2VxPTQxIHR0bD0yNTQgdGltZT0xNTQ1IG1zCj4gPiA+Cj4gPiA+ IEtpbGwgdGhlIGRvd25sb2FkIHF1ZXVlcyBlbXB0eSBhbmQgcGluZyB0aW1lcyByZXR1cm4gdG8g bm9ybWFsCj4gPiA+Cj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTAgOiBpY21wX3NlcT00 MiB0dGw9MjU0IHRpbWU9OTc1IG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4xOTIuMTA6IGlj bXBfc2VxPTQzIHR0bD0yNTQgdGltZT02Ny40IG1zCj4gPiA+IDY0IGJ5dGVzIGZyb20gNjcuMC4x OTIuMTA6IGljbXBfc2VxPTQ0IHR0bD0yNTQgdGltZT0gNzMuNiBtcwo+ID4gPiA2NCBieXRlcyBm cm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT00NSB0dGw9MjU0IHRpbWU9NDUuMiBtcwo+ID4gPiA2 NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT00NiB0dGw9MjU0IHRpbWU9NDUuMiBt cwo+ID4gPiA2NCBieXRlcyBmcm9tIDY3LjAuMTkyLjEwOiBpY21wX3NlcT00NyB0dGw9MjU0IHRp bWU9NDQuOCBtcwo+ID4gPgo+ID4gPgo+ID4gPiBBbmQsIGhlcmUncyB0aGUgc2hlbGwgY29tbWFu ZHMgYW5kIHRoZWlyIG91dHB1dDoKPiA+ID4KPiA+ID4gcm9vdEBEZXZpbDp+ICMgc2ggLXggd3No YXBlci5odGIKPiA+ID4gKyBET1dOTElOSz0xMDAKPiA+ID4gKyBVUExJTks9MTAwCj4gPiA+ICsg REVWPWV0aDAKPiA+ID4gKyBOT1BSSU9IT1NUU1JDPQo+ID4gPiAgKyBOT1BSSU9IT1NURFNUPQo+ ID4gPiArIE5PUFJJT1BPUlRTUkM9Cj4gPiA+ICsgTk9QUklPUE9SVERTVD0KPiA+ID4gKyAnWycg JycgPSBzdGF0dXMgJ10nCj4gPiA+ICsgdGMgcWRpc2MgZGVsIGRldiBldGgwIHJvb3QKPiA+ID4g KyB0YyBxZGlzYyBkZWwgZGV2IGV0aDAgaW5ncmVzcwo+ID4gPiArICdbJyAnJyA9IHN0b3AgJ10n Cj4gPiA+ICsgdGMgcWRpc2MgYWRkIGRldiBldGgwIHJvb3QgaGFuZGxlIDE6IGh0YiBkZWZhdWx0 IDIwCj4gPiA+ICsgdGMgY2xhc3MgYWRkIGRldiBldGgwIHBhcmVudCAxOiBjbGFzc2lkIDE6MSBo dGIgcmF0ZSAxMDBrYml0IGJ1cnN0IDZrCj4gPiA+ICsgdGMgY2xhc3MgYWRkIGRldiBldGgwIHBh cmVudCAxOjEgY2xhc3NpZCAxOjEwIGh0YiByYXRlIDEwMGtiaXQgYnVyc3QgNmsKPiBwcmlvIDEK PiA+ID4gKyB0YyBjbGFzcyBhZGQgZGV2IGV0aDAgcGFyZW50IDE6MSBjbGFzc2lkIDE6MjAgaHRi IHJhdGUgOTBrYml0IGJ1cnN0IDZrCj4gcHJpbyAyCj4gPiA+ICsgdGMgY2xhc3MgYWRkIGRldiBl dGgwIHBhcmVudCAxOjEgY2xhc3NpZCAxOjMwIGh0YiByYXRlIDgwa2JpdCBidXJzdCA2awo+IHBy aW8gMgo+ID4gPiArIHRjIHFkaXNjIGFkZCBkZXYgZXRoMCBwYXJlbnQgMToxMCBoYW5kbGUgMTA6 IHNmcSBwZXJ0dXJiIDEwCj4gPiA+ICsgdGMgcWRpc2MgYWRkIGRldiBldGgwIHBhcmVudCAxOjIw IGhhbmRsZSAyMDogc2ZxIHBlcnR1cmIgMTAKPiA+ID4gKyB0YyBxZGlzYyBhZGQgZGV2IGV0aDAg cGFyZW50IDE6MzAgaGFuZGxlIDMwOiBzZnEgcGVydHVyYiAxMAo+ID4gPiArIHRjIGZpbHRlciBh ZGQgZGV2IGV0aDAgcGFyZW50IDE6MCBwcm90b2NvbCBpcCBwcmlvIDEwIHUzMiBtYXRjaCBpcAo+ ID4gPiB0b3MgMHgxMCAweGZmIGZsb3dpZCAxOjEwCj4gPiA+ICsgdGMgZmlsdGVyIGFkZCBkZXYg ZXRoMCBwYXJlbnQgMTowIHByb3RvY29sIGlwIHByaW8gMTAgdTMyIG1hdGNoIGlwCj4gPiA+IHBy b3RvY29sIDEgMHhmZiBmbG93aWQgMToxMAo+ID4gPiArIHRjIGZpbHRlciBhZGQgZGV2IGV0aDAg cGFyZW50IDE6IHByb3RvY29sIGlwIHByaW8gMTAgdTMyIG1hdGNoIGlwCj4gPiA+IHByb3RvY29s IDYgMHhmZiBtYXRjaCB1OCAweDA1IDB4MGYgYXQgMCBtYXRjaCB1MTYgMHgwMDAwIDB4ZmZjMCBh dCAyCj4gPiA+IG1hdGNoIHU4IDB4MTAgMHhmZiBhdCAzMyBmbG93aWQgMToxMAo+ID4gPiArIHRj IGZpbHRlciBhZGQgZGV2IGV0aDAgcGFyZW50IDE6IHByb3RvY29sIGlwIHByaW8gMTggdTMyIG1h dGNoIGlwCj4gPiA+IGRzdCAwLjAuMC4wLzAgZmxvd2lkIDE6MjAKPiA+ID4gKyB0YyBxZGlzYyBh ZGQgZGV2IGV0aDAgaGFuZGxlIGZmZmY6IGluZ3Jlc3MKPiA+ID4gKyB0YyBmaWx0ZXIgYWRkIGRl diBldGgwIHBhcmVudCBmZmZmOiBwcm90b2NvbCBpcCBwcmlvIDUwIHUzMiBtYXRjaCBpcAo+ID4g PiBzcmMgMC4wLjAuMC8wIHBvbGljZSByYXRlIDEwMGtiaXQgYnVyc3QgMTBrIGRyb3AgZmxvd2lk IDoxCj4gPiA+Cj4gPiA+Cj4gPiA+IHJvb3RARGV2aWw6fiAjIHNoIC14IHdzaGFwZXIuaHRiIHN0 YXR1cwo+ID4gPiArIERPV05MSU5LPTEwMAo+ID4gPiArIFVQTElOSz0xMDAKPiA+ID4gKyBERVY9 ZXRoMAo+ID4gPiArIE5PUFJJT0hPU1RTUkM9Cj4gPiA+ICsgTk9QUklPSE9TVERTVD0KPiA+ID4g KyBOT1BSSU9QT1JUU1JDPQo+ID4gPiArIE5PUFJJT1BPUlREU1Q9Cj4gPiA+ICsgJ1snIHN0YXR1 cyA9IHN0YXR1cyAnXScKPiA+ID4gKyB0YyAtcyBxZGlzYyBscyBkZXYgZXRoMAo+ID4gPiBxZGlz YyBodGIgMTogcjJxIDEwIGRlZmF1bHQgMjAgZGlyZWN0X3BhY2tldHNfc3RhdCAwCj4gPiA+ICBT ZW50IDE4NjQ5IGJ5dGVzIDE5MSBwa3RzIChkcm9wcGVkIDAsIG92ZXJsaW1pdHMgMCkKPiA+ID4g cWRpc2Mgc2ZxIDEwOiBwYXJlbnQgMToxMCBsaW1pdCAxMjhwIHF1YW50dW0gMTUxNGIgcGVydHVy YiAxMHNlYwo+ID4gPiAgU2VudCAxMDU4MiBieXRlcyAxNDcgcGt0cyAoZHJvcHBlZCAwLCBvdmVy bGltaXRzIDApCj4gPiA+IHFkaXNjIHNmcSAyMDogcGFyZW50IDE6MjAgbGltaXQgMTI4cCBxdWFu dHVtIDE1MTRiIHBlcnR1cmIgMTBzZWMKPiA+ID4gIFNlbnQgODA2NyBieXRlcyA0NCBwa3RzIChk cm9wcGVkIDAsIG92ZXJsaW1pdHMgMCkKPiA+ID4gcWRpc2Mgc2ZxIDMwOiBwYXJlbnQgMTozMCBs aW1pdCAxMjhwIHF1YW50dW0gMTUxNGIgcGVydHVyYiAxMHNlYwo+ID4gPiAgU2VudCAwIGJ5dGVz IDAgcGt0cyAoZHJvcHBlZCAwLCBvdmVybGltaXRzIDApCj4gPiA+IHFkaXNjIGluZ3Jlc3MgZmZm ZjogLS0tLS0tLS0tLS0tLS0tLQo+ID4gPiAgU2VudCAwIGJ5dGVzIDAgcGt0cyAoZHJvcHBlZCAw LCBvdmVybGltaXRzIDApCj4gPiA+ICsgdGMgLXMgY2xhc3MgbHMgZGV2IGV0aDAKPiA+ID4gY2xh c3MgaHRiIDE6MSByb290IHJhdGUgMTAwMDAwYml0IGNlaWwgMTAwMDAwYml0IGJ1cnN0IDZLYiBj YnVyc3QgMTcyNGIKPiA+ID4gIFNlbnQgMTg2NDkgYnl0ZXMgMTkxIHBrdHMgKGRyb3BwZWQgMCwg b3ZlcmxpbWl0cyAwKQo+ID4gPiAgcmF0ZSAxMzIwYml0IDFwcHMKPiA+ID4gIGxlbmRlZDogMCBi b3Jyb3dlZDogMCBnaWFudHM6IDAKPiA+ID4gIHRva2VuczogMzk4NDU5IGN0b2tlbnM6IDEwODg1 NQo+ID4gPgo+ID4gPiBjbGFzcyBodGIgMToxMCBwYXJlbnQgMToxIGxlYWYgMTA6IHByaW8gMSBy YXRlIDEwMDAwMGJpdCBjZWlsCj4gPiA+IDEwMDAwMGJpdCBidXJzdCA2S2IgY2J1cnN0IDE3MjRi Cj4gPiA+ICBTZW50IDEwNTgyIGJ5dGVzIDE0NyBwa3RzIChkcm9wcGVkIDAsIG92ZXJsaW1pdHMg MCkKPiA+ID4gIHJhdGUgNjU2Yml0IDFwcHMKPiA+ID4gIGxlbmRlZDogMTQ3IGJvcnJvd2VkOiAw IGdpYW50czogMAo+ID4gPiAgdG9rZW5zOiAzOTg0NTkgY3Rva2VuczogMTA4ODU1Cj4gPiA+Cj4g PiA+IGNsYXNzIGh0YiAxOjIwIHBhcmVudCAxOjEgbGVhZiAyMDogcHJpbyAyIHJhdGUgOTAwMDBi aXQgY2VpbCA5MDAwMGJpdAo+ID4gPiBidXJzdCA2S2IgY2J1cnN0IDE3MTFiCj4gPiA+ICBTZW50 IDgwNjcgYnl0ZXMgNDQgcGt0cyAoZHJvcHBlZCAwLCBvdmVybGltaXRzIDApCj4gPiA+ICByYXRl IDcxMmJpdAo+ID4gPiAgbGVuZGVkOiA0NCBib3Jyb3dlZDogMCBnaWFudHM6IDAKPiA+ID4gIHRv a2VuczogNDMyMjg0IGN0b2tlbnM6IDEwOTU1NQo+ID4gPgo+ID4gPiBjbGFzcyBodGIgMTozMCBw YXJlbnQgMToxIGxlYWYgMzA6IHByaW8gMiByYXRlIDgwMDAwYml0IGNlaWwgODAwMDBiaXQKPiA+ ID4gYnVyc3QgNktiIGNidXJzdCAxNjk5Ygo+ID4gPiAgU2VudCAwIGJ5dGVzIDAgcGt0cyAoZHJv cHBlZCAwLCBvdmVybGltaXRzIDApCj4gPiA+ICBsZW5kZWQ6IDAgYm9ycm93ZWQ6IDAgZ2lhbnRz OiAwCj4gPiA+ICB0b2tlbnM6IDUwMzMxNiBjdG9rZW5zOiAxMzkyNjQKPiA+ID4KPiA+ID4gKyBl eGl0Cj4gPiA+IHJvb3RARGV2aWw6fiAjIHNoIC14IHdzaGFwZXIuaHRiIHN0b3AKPiA+ID4gKyBE T1dOTElOSz0xMDAKPiA+ID4gKyBVUExJTks9MTAwCj4gPiA+ICsgREVWPWV0aDAKPiA+ID4gKyBO T1BSSU9IT1NUU1JDPQo+ID4gPiArIE5PUFJJT0hPU1REU1Q9Cj4gPiA+ICsgTk9QUklPUE9SVFNS Qz0KPiA+ID4gKyBOT1BSSU9QT1JURFNUPQo+ID4gPiArICdbJyBzdG9wID0gc3RhdHVzICddJwo+ ID4gPiArIHRjIHFkaXNjIGRlbCBkZXYgZXRoMCByb290Cj4gPiA+ICsgdGMgcWRpc2MgZGVsIGRl diBldGgwIGluZ3Jlc3MKPiA+ID4gKyAnWycgc3RvcCA9IHN0b3AgJ10nCj4gPiA+ICsgZXhpdAo+ ID4gPgo+ID4gPiByb290QERldmlsIDp+ICMKPiA+ID4KPiA+ID4gRG9uJ3QgdGhpbmsgd2UgZ2Vu ZXJhdGVkIGVub3VnaCB1cGxpbmsgdHJhZmZpYyB0byBleGVyY2lzZSB0aGUgaHRiIHFkaXNjcy4K PiA+ID4KPiA+ID4gQnV0IGl0IGRvZXNuJ3QgbG9vayBsaWtlIHRoZSBpbmdyZXNzIHFkaXNjIGlz IHdvcmtpbmcgYXQgYWxsLgo+ID4gPgo+ID4gPiBJJ20gb3V0IG9mIGlkZWFzIGZvciBub3cuCj4g PiA+Cj4gPiAtLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQo+ID4gVmVyc2lvbjogR251UEcg djEuNC4yLjIgKEdOVS9MaW51eCkKPiA+Cj4gPiBpRDREQlFGRllpSkRKNjJreGtTQ3RMQVJBb0NT QUppQWk5VldQUE54eTJxN05rSCtwVHZoU3B0YkFKOTMwajB6Cj4gPiBLUy8rOHh6MkpvVmNTRG04 dGFhRElBPT0KPiA+ID1KcGhpCj4gPiAtLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0KPiA+Cj4g PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCj4gPiBUYWtlIFN1cnZleXMuIEVhcm4gQ2FzaC4gSW5mbHVlbmNl IHRoZSBGdXR1cmUgb2YgSVQKPiA+IEpvaW4gU291cmNlRm9yZ2UubmV0J3MgVGVjaHNheSBwYW5l bCBhbmQgeW91J2xsIGdldCB0aGUgY2hhbmNlIHRvCj4gPiBzaGFyZSB5b3VyIG9waW5pb25zIG9u IElUICYgYnVzaW5lc3MgdG9waWNzIHRocm91Z2ggYnJpZWYgc3VydmV5cyAtCj4gPiAgYW5kIGVh cm4gY2FzaAo+IGh0dHA6Ly93d3cudGVjaHNheS5jb20vZGVmYXVsdC5waHA/cGFnZT1qb2luLnBo cCZwPXNvdXJjZWZvcmdlJkNJRD1ERVZERVYKPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4gPiBEZXZpbC1saW51eC1kaXNjdXNzIG1haWxpbmcgbGlz dAo+ID4gRGV2aWwtbGludXgtZGlzY3Vzc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiA+IGh0dHBz Oi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2RldmlsLWxpbnV4LWRpc2N1 c3MKPiAtLS0tLS0tIEVuZCBvZiBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0KPgo+Cj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQo+IFRha2UgU3VydmV5cy4gRWFybiBDYXNoLiBJbmZsdWVuY2UgdGhlIEZ1dHVy ZSBvZiBJVAo+IEpvaW4gU291cmNlRm9yZ2UubmV0J3MgVGVjaHNheSBwYW5lbCBhbmQgeW91J2xs IGdldCB0aGUgY2hhbmNlIHRvIHNoYXJlIHlvdXIKPiBvcGluaW9ucyBvbiBJVCAmIGJ1c2luZXNz IHRvcGljcyB0aHJvdWdoIGJyaWVmIHN1cnZleXMgLSBhbmQgZWFybiBjYXNoCj4gaHR0cDovL3d3 dy50ZWNoc2F5LmNvbS9kZWZhdWx0LnBocD9wYWdlPWpvaW4ucGhwJnA9c291cmNlZm9yZ2UmQ0lE PURFVkRFVgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4gRGV2aWwtbGludXgtZGlzY3VzcyBtYWlsaW5nIGxpc3QKPiBEZXZpbC1saW51eC1kaXNjdXNz QGxpc3RzLnNvdXJjZWZvcmdlLm5ldAo+IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xp c3RzL2xpc3RpbmZvL2RldmlsLWxpbnV4LWRpc2N1c3MKPgoKCi0tIApEcmV3IEVpbmhvcm4K |
|
From: Kari M. <kar...@tr...> - 2006-11-20 22:11:29
|
Dick Middleton wrote:
> Bruce Smith wrote:
>>>> Do either of those packages start by _default_ when you boot DL?
>>>>
>>> Yes. Any program/script placed in /etc/cron.daily for example will be executed
>>> as root. So far as I know this is the only way aide is executed. Had aide
>>> install been good then everybody would be running it whether they wanted to or
>>> not. There's a thing called logwatch also arrived in this DL version which does
>>> work. It is also started in cron.daily. First I knew about it was its report
>>> in my inbox.
>>>
>> OK, maybe the line in the crontab should be commented out by default.
>> (I'll leave that decision to Heiko)
> >
>> OTOH, the last time I checked, crond itself doesn't start by default.
>> And if/when you turn on cron, you it's a good idea to edit/check the
>> crontabs.
>
> I think this is uncovering more than I intended but since we've started, in my
> opinion DL should not have scripts for packages installed in cron.daily etc.
> Instead I suggest it should place them in some other directory. It should then
> create symbolic links from cron.daily to the script at bootup if the package is
> enabled in sysconfig/config. Then it's similar to the way init.d works. That
> way DL retains some visibility and control of what is enabled and does not risk
> activating scripts unintentionally or unexpectedly.
I have to disagree on this, at least somewhat. First, it is customary
for people to make at least some changes to the scripts in cron.* dirs.
They have to remain writable. Second, creating automation to enable
certain links/scripts when a service is activated in
/etc/sysconfig/config, is, to my mind, wasting resources. You would,
for example have to specify wether to make the link into
cron.{hourly|daily|weekly|monthly|d}...
The Germans say, "Nein danke", and I say no thanks, too.
> Dick
-Kari ..not from Germany :-|
|
|
From: Dr. A. B. <be...@ec...> - 2006-11-20 22:11:00
|
I have a working version of arbitrator in Devil-Linux (in production server!), but it's very difficult mantain this project (two years ago I bought a rpm version for kernel 2.4.21) because the kernel patch it's not very well and now little maintained for GPL version. In website there is a minihowto for 2.4.30 (http://www.bandwidtharbitrator.com/modules.php?name=News&file=article&sid=32) that is a synthesis of job (one year ago) in Devil-Linux. If you think it could be of interest, I could publish scripts and patch for 2.4.33 There is a project that, I think, an advanced traffic shaping, see yo: http://tcng.sourceforge.net http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO There always little time ... Regards Alberto +--------------------------+ | Dott. Alberto Benati | | System Administrator | | Faculty of Economics | | University of Ferrara | | be...@ec... | | Tel: +39 0532 45 5012 | +--------------------------+ ---------- Original Message ----------- From: cdmiller <cdm...@ad...> To: dev...@li... Sent: Mon, 20 Nov 2006 14:46:43 -0700 Subject: Re: [Devil-Linux-discuss] Fwd: Traffic Shaping on a Transparent Bridge not working! > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Not sure if it helps, but you may also want to look at bandwidth arbitrator: > > http://www.bandwidtharbitrator.com/ > > It does require a patched kernel so you would have to do a devil- > linux compilation. I had been planning to try it on Devil, just haven't > gotten around to it yet. > > - - cameron > > drew einhorn wrote: > > Trying again. Hope I'm finally off the bogus email blacklist, and > > this goes through. > > > > ---------- Forwarded message ---------- > > From: drew einhorn <dre...@gm...> > > Date: Nov 19, 2006 11:51 PM > > Subject: Traffic Shaping on a Transparent Bridge not working! > > To: dev...@li... > > > > > > My first DL project was going well. Then I ran into problems attempting > > to shape my bandwidth. > > > > First I'll describe the parts that I believe are working correctly. > > > > I have a DL 1.2.11 box running the default kernel, 2.4.33.3-grsec > > > > I have br0 bridging all four ports eth0, eth1, eth2, eth3 on a quad port > > pci card. The bridge has not been assigned an ip number on the theory > > that this makes it much more difficult to attack. The bridge connects > > four devices on the 3bit public static ip block from my ISP. > > > > I have a single port ethernet pci card, eth4 with a static ip, on my > > internal private ip network. It is used for remote managent of the DL > > box from anywhere on my internal network. > > > > eth0 is connected to my ISP's router via the ethernet port on my > > ISDN modem. I know ISDN is a nearly dead technology, but it's the best > > thing my crappy telco offers. Tried a satellite ISP, but that's another > > long story. > > > > eth1 is connected to a hardened publicly accessible host. > > > > eth2 and eth3 are connected to the WAN ports on a couple of Linksys > > Cable/DSL routers. Eventually most of their functions will migrate to the > > DL box, but that is more than I wanted to bite off in my first DL project. > > > > The first Linksys box NATs one of my public ips to my internal private > > ip network. The second Linksys box is newer and includes a wireless > > access point used by a couple neighbors. It NATs a second public ip to > > a separate private ip network. > > > > All of the above appears to be working as expected. > > > > After pondering the mysteries of traffic shaping I decided to start with > > wondershaper 1.1a from lartc.org, rather than starting from scratch. > > > > Tried both the cbq and htb versions without any success. > > > > RTFM time. The htb section of http://lartc.org/howto/index.html is easier > > reading than the cbq section. And the howto claims htb is better anyway. > > Let's focus on the htb version of wondershaper. > > > > OK, First we edit wshaper.htb and configure the shell variables. Then we > > run: sh -x wshaper.htb > > to echo the commands as they are executed. > > > > Then we start pinging the router at the other end of the ISDN line. > > > > Then we start downloading a file to generate some traffic that really > > needs to be shaped. > > > > Then we run: sh -x wshaper.htb status > > to gather some statistics > > > > then we kill the download. > > > > then we sh -x wshaper.htb stop to shut down the malfunctioning shaper. > > > > Here's the output from the ping: > > > > $ ping 67.0.192.10 > > PING 67.0.192.10 (67.0.192.10) 56(84) bytes of data. > > > > Link is idle, normal ping times. > > > > 64 bytes from 67.0.192.10: icmp_seq=0 ttl=254 time=48.5 ms > > 64 bytes from 67.0.192.10: icmp_seq=1 ttl=254 time=48.4 ms > > 64 bytes from 67.0.192.10: icmp_seq=2 ttl=254 time=48.4 ms > > 64 bytes from 67.0.192.10: icmp_seq=3 ttl=254 time=48.4 ms > > 64 bytes from 67.0.192.10: icmp_seq=4 ttl=254 time= 48.5 ms > > 64 bytes from 67.0.192.10: icmp_seq=5 ttl=254 time=67.8 ms > > 64 bytes from 67.0.192.10: icmp_seq=6 ttl=254 time=48.3 ms > > 64 bytes from 67.0.192.10: icmp_seq=7 ttl=254 time=48.2 ms > > > > Download starts. Shaping is not working! Queues in > > router and/or ISDN modem grow, and ping times rapidly > > become huge. > > > > 64 bytes from 67.0.192.10: icmp_seq=8 ttl=254 time=184 ms > > 64 bytes from 67.0.192.10: icmp_seq=9 ttl=254 time=1080 ms > > 64 bytes from 67.0.192.10: icmp_seq=10 ttl=254 time=2025 ms > > 64 bytes from 67.0.192.10: icmp_seq=11 ttl=254 time=1551 ms > > 64 bytes from 67.0.192.10: icmp_seq=12 ttl=254 time=1078 ms > > 64 bytes from 67.0.192.10: icmp_seq=13 ttl=254 time=896 ms > > 64 bytes from 67.0.192.10: icmp_seq=14 ttl=254 time=1088 ms > > 64 bytes from 67.0.192.10: icmp_seq=15 ttl=254 time=1171 ms > > 64 bytes from 67.0.192.10: icmp_seq=16 ttl=254 time=1272 ms > > 64 bytes from 67.0.192.10: icmp_seq=17 ttl=254 time=1280 ms > > 64 bytes from 67.0.192.10: icmp_seq=18 ttl=254 time=1101 ms > > 64 bytes from 67.0.192.10: icmp_seq=19 ttl=254 time=1258 ms > > 64 bytes from 67.0.192.10: icmp_seq=20 ttl=254 time=1211 ms > > 64 bytes from 67.0.192.10: icmp_seq=21 ttl=254 time=1259 ms > > 64 bytes from 67.0.192.10: icmp_seq=22 ttl=254 time=1373 ms > > 64 bytes from 67.0.192.10: icmp_seq=23 ttl=254 time=1424 ms > > 64 bytes from 67.0.192.10: icmp_seq=24 ttl=254 time=1461 ms > > 64 bytes from 67.0.192.10: icmp_seq=25 ttl=254 time=1277 ms > > 64 bytes from 67.0.192.10: icmp_seq=26 ttl=254 time=1521 ms > > 64 bytes from 67.0.192.10: icmp_seq=27 ttl=254 time=1467 ms > > 64 bytes from 67.0.192.10: icmp_seq=28 ttl=254 time=1335 ms > > 64 bytes from 67.0.192.10: icmp_seq=29 ttl=254 time=1329 ms > > 64 bytes from 67.0.192.10: icmp_seq=30 ttl=254 time=1386 ms > > 64 bytes from 67.0.192.10: icmp_seq=31 ttl=254 time=1360 ms > > 64 bytes from 67.0.192.10: icmp_seq=32 ttl=254 time=1416 ms > > 64 bytes from 67.0.192.10: icmp_seq=33 ttl=254 time=1480 ms > > 64 bytes from 67.0.192.10: icmp_seq=34 ttl=254 time=1345 ms > > 64 bytes from 67.0.192.10: icmp_seq=35 ttl=254 time=1356 ms > > 64 bytes from 67.0.192.10: icmp_seq=36 ttl=254 time=1370 ms > > 64 bytes from 67.0.192.10: icmp_seq=37 ttl=254 time=1278 ms > > 64 bytes from 67.0.192.10: icmp_seq=38 ttl=254 time=1612 ms > > 64 bytes from 67.0.192.10: icmp_seq=39 ttl=254 time=1520 ms > > 64 bytes from 67.0.192.10: icmp_seq=40 ttl=254 time=1322 ms > > 64 bytes from 67.0.192.10: icmp_seq=41 ttl=254 time=1545 ms > > > > Kill the download queues empty and ping times return to normal > > > > 64 bytes from 67.0.192.10 : icmp_seq=42 ttl=254 time=975 ms > > 64 bytes from 67.0.192.10: icmp_seq=43 ttl=254 time=67.4 ms > > 64 bytes from 67.0.192.10: icmp_seq=44 ttl=254 time= 73.6 ms > > 64 bytes from 67.0.192.10: icmp_seq=45 ttl=254 time=45.2 ms > > 64 bytes from 67.0.192.10: icmp_seq=46 ttl=254 time=45.2 ms > > 64 bytes from 67.0.192.10: icmp_seq=47 ttl=254 time=44.8 ms > > > > > > And, here's the shell commands and their output: > > > > root@Devil:~ # sh -x wshaper.htb > > + DOWNLINK=100 > > + UPLINK=100 > > + DEV=eth0 > > + NOPRIOHOSTSRC= > > + NOPRIOHOSTDST= > > + NOPRIOPORTSRC= > > + NOPRIOPORTDST= > > + '[' '' = status ']' > > + tc qdisc del dev eth0 root > > + tc qdisc del dev eth0 ingress > > + '[' '' = stop ']' > > + tc qdisc add dev eth0 root handle 1: htb default 20 > > + tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbit burst 6k > > + tc class add dev eth0 parent 1:1 classid 1:10 htb rate 100kbit burst 6k prio 1 > > + tc class add dev eth0 parent 1:1 classid 1:20 htb rate 90kbit burst 6k prio 2 > > + tc class add dev eth0 parent 1:1 classid 1:30 htb rate 80kbit burst 6k prio 2 > > + tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 > > + tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 > > + tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10 > > + tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip > > tos 0x10 0xff flowid 1:10 > > + tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip > > protocol 1 0xff flowid 1:10 > > + tc filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip > > protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 > > match u8 0x10 0xff at 33 flowid 1:10 > > + tc filter add dev eth0 parent 1: protocol ip prio 18 u32 match ip > > dst 0.0.0.0/0 flowid 1:20 > > + tc qdisc add dev eth0 handle ffff: ingress > > + tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip > > src 0.0.0.0/0 police rate 100kbit burst 10k drop flowid :1 > > > > > > root@Devil:~ # sh -x wshaper.htb status > > + DOWNLINK=100 > > + UPLINK=100 > > + DEV=eth0 > > + NOPRIOHOSTSRC= > > + NOPRIOHOSTDST= > > + NOPRIOPORTSRC= > > + NOPRIOPORTDST= > > + '[' status = status ']' > > + tc -s qdisc ls dev eth0 > > qdisc htb 1: r2q 10 default 20 direct_packets_stat 0 > > Sent 18649 bytes 191 pkts (dropped 0, overlimits 0) > > qdisc sfq 10: parent 1:10 limit 128p quantum 1514b perturb 10sec > > Sent 10582 bytes 147 pkts (dropped 0, overlimits 0) > > qdisc sfq 20: parent 1:20 limit 128p quantum 1514b perturb 10sec > > Sent 8067 bytes 44 pkts (dropped 0, overlimits 0) > > qdisc sfq 30: parent 1:30 limit 128p quantum 1514b perturb 10sec > > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > > qdisc ingress ffff: ---------------- > > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > > + tc -s class ls dev eth0 > > class htb 1:1 root rate 100000bit ceil 100000bit burst 6Kb cburst 1724b > > Sent 18649 bytes 191 pkts (dropped 0, overlimits 0) > > rate 1320bit 1pps > > lended: 0 borrowed: 0 giants: 0 > > tokens: 398459 ctokens: 108855 > > > > class htb 1:10 parent 1:1 leaf 10: prio 1 rate 100000bit ceil > > 100000bit burst 6Kb cburst 1724b > > Sent 10582 bytes 147 pkts (dropped 0, overlimits 0) > > rate 656bit 1pps > > lended: 147 borrowed: 0 giants: 0 > > tokens: 398459 ctokens: 108855 > > > > class htb 1:20 parent 1:1 leaf 20: prio 2 rate 90000bit ceil 90000bit > > burst 6Kb cburst 1711b > > Sent 8067 bytes 44 pkts (dropped 0, overlimits 0) > > rate 712bit > > lended: 44 borrowed: 0 giants: 0 > > tokens: 432284 ctokens: 109555 > > > > class htb 1:30 parent 1:1 leaf 30: prio 2 rate 80000bit ceil 80000bit > > burst 6Kb cburst 1699b > > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > > lended: 0 borrowed: 0 giants: 0 > > tokens: 503316 ctokens: 139264 > > > > + exit > > root@Devil:~ # sh -x wshaper.htb stop > > + DOWNLINK=100 > > + UPLINK=100 > > + DEV=eth0 > > + NOPRIOHOSTSRC= > > + NOPRIOHOSTDST= > > + NOPRIOPORTSRC= > > + NOPRIOPORTDST= > > + '[' stop = status ']' > > + tc qdisc del dev eth0 root > > + tc qdisc del dev eth0 ingress > > + '[' stop = stop ']' > > + exit > > > > root@Devil :~ # > > > > Don't think we generated enough uplink traffic to exercise the htb qdiscs. > > > > But it doesn't look like the ingress qdisc is working at all. > > > > I'm out of ideas for now. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) > > iD4DBQFFYiJDJ62kxkSCtLARAoCSAJiAi9VWPPNxy2q7NkH+pTvhSptbAJ930j0z > KS/+8xz2JoVcSDm8taaDIA== > =Jphi > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your opinions on IT & business topics through brief surveys - > and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Devil-linux-discuss mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss ------- End of Original Message ------- |
|
From: drew e. <dre...@gm...> - 2006-11-20 22:00:02
|
Hmm. They weren't showing up in MY inbox. So I thought they were just vanishing. Have to check if some flag is set incorrectly on the maillist account. Thanks, On 11/20/06, Heiko Zuerker <he...@zu...> wrote: > > On Mon, November 20, 2006 15:10, drew einhorn wrote: > > Trying again. Hope I'm finally off the bogus email blacklist, and > > this goes through. > > Your emails are arriving. > It just looks like nobody is able to help you. :-( > > -- > > Regards > Heiko Zuerker > http://www.devil-linux.org > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Devil-linux-discuss mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss > -- Drew Einhorn |
|
From: Dick M. <di...@li...> - 2006-11-20 21:51:55
|
Bruce Smith wrote: >>> Do either of those packages start by _default_ when you boot DL? >>> >> Yes. Any program/script placed in /etc/cron.daily for example will be executed >> as root. So far as I know this is the only way aide is executed. Had aide >> install been good then everybody would be running it whether they wanted to or >> not. There's a thing called logwatch also arrived in this DL version which does >> work. It is also started in cron.daily. First I knew about it was its report >> in my inbox. >> > > OK, maybe the line in the crontab should be commented out by default. > (I'll leave that decision to Heiko) > > OTOH, the last time I checked, crond itself doesn't start by default. > And if/when you turn on cron, you it's a good idea to edit/check the > crontabs. I think this is uncovering more than I intended but since we've started, in my opinion DL should not have scripts for packages installed in cron.daily etc. Instead I suggest it should place them in some other directory. It should then create symbolic links from cron.daily to the script at bootup if the package is enabled in sysconfig/config. Then it's similar to the way init.d works. That way DL retains some visibility and control of what is enabled and does not risk activating scripts unintentionally or unexpectedly. Dick |
|
From: cdmiller <cdm...@ad...> - 2006-11-20 21:46:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Not sure if it helps, but you may also want to look at bandwidth arbitrator: http://www.bandwidtharbitrator.com/ It does require a patched kernel so you would have to do a devil-linux compilation. I had been planning to try it on Devil, just haven't gotten around to it yet. - - cameron drew einhorn wrote: > Trying again. Hope I'm finally off the bogus email blacklist, and > this goes through. > > ---------- Forwarded message ---------- > From: drew einhorn <dre...@gm...> > Date: Nov 19, 2006 11:51 PM > Subject: Traffic Shaping on a Transparent Bridge not working! > To: dev...@li... > > > My first DL project was going well. Then I ran into problems attempting > to shape my bandwidth. > > First I'll describe the parts that I believe are working correctly. > > I have a DL 1.2.11 box running the default kernel, 2.4.33.3-grsec > > I have br0 bridging all four ports eth0, eth1, eth2, eth3 on a quad port > pci card. The bridge has not been assigned an ip number on the theory > that this makes it much more difficult to attack. The bridge connects > four devices on the 3bit public static ip block from my ISP. > > I have a single port ethernet pci card, eth4 with a static ip, on my > internal private ip network. It is used for remote managent of the DL > box from anywhere on my internal network. > > eth0 is connected to my ISP's router via the ethernet port on my > ISDN modem. I know ISDN is a nearly dead technology, but it's the best > thing my crappy telco offers. Tried a satellite ISP, but that's another > long story. > > eth1 is connected to a hardened publicly accessible host. > > eth2 and eth3 are connected to the WAN ports on a couple of Linksys > Cable/DSL routers. Eventually most of their functions will migrate to the > DL box, but that is more than I wanted to bite off in my first DL project. > > The first Linksys box NATs one of my public ips to my internal private > ip network. The second Linksys box is newer and includes a wireless > access point used by a couple neighbors. It NATs a second public ip to > a separate private ip network. > > All of the above appears to be working as expected. > > After pondering the mysteries of traffic shaping I decided to start with > wondershaper 1.1a from lartc.org, rather than starting from scratch. > > Tried both the cbq and htb versions without any success. > > RTFM time. The htb section of http://lartc.org/howto/index.html is easier > reading than the cbq section. And the howto claims htb is better anyway. > Let's focus on the htb version of wondershaper. > > OK, First we edit wshaper.htb and configure the shell variables. Then we > run: sh -x wshaper.htb > to echo the commands as they are executed. > > Then we start pinging the router at the other end of the ISDN line. > > Then we start downloading a file to generate some traffic that really > needs to be shaped. > > Then we run: sh -x wshaper.htb status > to gather some statistics > > then we kill the download. > > then we sh -x wshaper.htb stop to shut down the malfunctioning shaper. > > Here's the output from the ping: > > $ ping 67.0.192.10 > PING 67.0.192.10 (67.0.192.10) 56(84) bytes of data. > > Link is idle, normal ping times. > > 64 bytes from 67.0.192.10: icmp_seq=0 ttl=254 time=48.5 ms > 64 bytes from 67.0.192.10: icmp_seq=1 ttl=254 time=48.4 ms > 64 bytes from 67.0.192.10: icmp_seq=2 ttl=254 time=48.4 ms > 64 bytes from 67.0.192.10: icmp_seq=3 ttl=254 time=48.4 ms > 64 bytes from 67.0.192.10: icmp_seq=4 ttl=254 time= 48.5 ms > 64 bytes from 67.0.192.10: icmp_seq=5 ttl=254 time=67.8 ms > 64 bytes from 67.0.192.10: icmp_seq=6 ttl=254 time=48.3 ms > 64 bytes from 67.0.192.10: icmp_seq=7 ttl=254 time=48.2 ms > > Download starts. Shaping is not working! Queues in > router and/or ISDN modem grow, and ping times rapidly > become huge. > > 64 bytes from 67.0.192.10: icmp_seq=8 ttl=254 time=184 ms > 64 bytes from 67.0.192.10: icmp_seq=9 ttl=254 time=1080 ms > 64 bytes from 67.0.192.10: icmp_seq=10 ttl=254 time=2025 ms > 64 bytes from 67.0.192.10: icmp_seq=11 ttl=254 time=1551 ms > 64 bytes from 67.0.192.10: icmp_seq=12 ttl=254 time=1078 ms > 64 bytes from 67.0.192.10: icmp_seq=13 ttl=254 time=896 ms > 64 bytes from 67.0.192.10: icmp_seq=14 ttl=254 time=1088 ms > 64 bytes from 67.0.192.10: icmp_seq=15 ttl=254 time=1171 ms > 64 bytes from 67.0.192.10: icmp_seq=16 ttl=254 time=1272 ms > 64 bytes from 67.0.192.10: icmp_seq=17 ttl=254 time=1280 ms > 64 bytes from 67.0.192.10: icmp_seq=18 ttl=254 time=1101 ms > 64 bytes from 67.0.192.10: icmp_seq=19 ttl=254 time=1258 ms > 64 bytes from 67.0.192.10: icmp_seq=20 ttl=254 time=1211 ms > 64 bytes from 67.0.192.10: icmp_seq=21 ttl=254 time=1259 ms > 64 bytes from 67.0.192.10: icmp_seq=22 ttl=254 time=1373 ms > 64 bytes from 67.0.192.10: icmp_seq=23 ttl=254 time=1424 ms > 64 bytes from 67.0.192.10: icmp_seq=24 ttl=254 time=1461 ms > 64 bytes from 67.0.192.10: icmp_seq=25 ttl=254 time=1277 ms > 64 bytes from 67.0.192.10: icmp_seq=26 ttl=254 time=1521 ms > 64 bytes from 67.0.192.10: icmp_seq=27 ttl=254 time=1467 ms > 64 bytes from 67.0.192.10: icmp_seq=28 ttl=254 time=1335 ms > 64 bytes from 67.0.192.10: icmp_seq=29 ttl=254 time=1329 ms > 64 bytes from 67.0.192.10: icmp_seq=30 ttl=254 time=1386 ms > 64 bytes from 67.0.192.10: icmp_seq=31 ttl=254 time=1360 ms > 64 bytes from 67.0.192.10: icmp_seq=32 ttl=254 time=1416 ms > 64 bytes from 67.0.192.10: icmp_seq=33 ttl=254 time=1480 ms > 64 bytes from 67.0.192.10: icmp_seq=34 ttl=254 time=1345 ms > 64 bytes from 67.0.192.10: icmp_seq=35 ttl=254 time=1356 ms > 64 bytes from 67.0.192.10: icmp_seq=36 ttl=254 time=1370 ms > 64 bytes from 67.0.192.10: icmp_seq=37 ttl=254 time=1278 ms > 64 bytes from 67.0.192.10: icmp_seq=38 ttl=254 time=1612 ms > 64 bytes from 67.0.192.10: icmp_seq=39 ttl=254 time=1520 ms > 64 bytes from 67.0.192.10: icmp_seq=40 ttl=254 time=1322 ms > 64 bytes from 67.0.192.10: icmp_seq=41 ttl=254 time=1545 ms > > Kill the download queues empty and ping times return to normal > > 64 bytes from 67.0.192.10 : icmp_seq=42 ttl=254 time=975 ms > 64 bytes from 67.0.192.10: icmp_seq=43 ttl=254 time=67.4 ms > 64 bytes from 67.0.192.10: icmp_seq=44 ttl=254 time= 73.6 ms > 64 bytes from 67.0.192.10: icmp_seq=45 ttl=254 time=45.2 ms > 64 bytes from 67.0.192.10: icmp_seq=46 ttl=254 time=45.2 ms > 64 bytes from 67.0.192.10: icmp_seq=47 ttl=254 time=44.8 ms > > > And, here's the shell commands and their output: > > root@Devil:~ # sh -x wshaper.htb > + DOWNLINK=100 > + UPLINK=100 > + DEV=eth0 > + NOPRIOHOSTSRC= > + NOPRIOHOSTDST= > + NOPRIOPORTSRC= > + NOPRIOPORTDST= > + '[' '' = status ']' > + tc qdisc del dev eth0 root > + tc qdisc del dev eth0 ingress > + '[' '' = stop ']' > + tc qdisc add dev eth0 root handle 1: htb default 20 > + tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbit burst 6k > + tc class add dev eth0 parent 1:1 classid 1:10 htb rate 100kbit burst 6k prio 1 > + tc class add dev eth0 parent 1:1 classid 1:20 htb rate 90kbit burst 6k prio 2 > + tc class add dev eth0 parent 1:1 classid 1:30 htb rate 80kbit burst 6k prio 2 > + tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 > + tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 > + tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10 > + tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip > tos 0x10 0xff flowid 1:10 > + tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip > protocol 1 0xff flowid 1:10 > + tc filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip > protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 > match u8 0x10 0xff at 33 flowid 1:10 > + tc filter add dev eth0 parent 1: protocol ip prio 18 u32 match ip > dst 0.0.0.0/0 flowid 1:20 > + tc qdisc add dev eth0 handle ffff: ingress > + tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip > src 0.0.0.0/0 police rate 100kbit burst 10k drop flowid :1 > > > root@Devil:~ # sh -x wshaper.htb status > + DOWNLINK=100 > + UPLINK=100 > + DEV=eth0 > + NOPRIOHOSTSRC= > + NOPRIOHOSTDST= > + NOPRIOPORTSRC= > + NOPRIOPORTDST= > + '[' status = status ']' > + tc -s qdisc ls dev eth0 > qdisc htb 1: r2q 10 default 20 direct_packets_stat 0 > Sent 18649 bytes 191 pkts (dropped 0, overlimits 0) > qdisc sfq 10: parent 1:10 limit 128p quantum 1514b perturb 10sec > Sent 10582 bytes 147 pkts (dropped 0, overlimits 0) > qdisc sfq 20: parent 1:20 limit 128p quantum 1514b perturb 10sec > Sent 8067 bytes 44 pkts (dropped 0, overlimits 0) > qdisc sfq 30: parent 1:30 limit 128p quantum 1514b perturb 10sec > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > qdisc ingress ffff: ---------------- > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > + tc -s class ls dev eth0 > class htb 1:1 root rate 100000bit ceil 100000bit burst 6Kb cburst 1724b > Sent 18649 bytes 191 pkts (dropped 0, overlimits 0) > rate 1320bit 1pps > lended: 0 borrowed: 0 giants: 0 > tokens: 398459 ctokens: 108855 > > class htb 1:10 parent 1:1 leaf 10: prio 1 rate 100000bit ceil > 100000bit burst 6Kb cburst 1724b > Sent 10582 bytes 147 pkts (dropped 0, overlimits 0) > rate 656bit 1pps > lended: 147 borrowed: 0 giants: 0 > tokens: 398459 ctokens: 108855 > > class htb 1:20 parent 1:1 leaf 20: prio 2 rate 90000bit ceil 90000bit > burst 6Kb cburst 1711b > Sent 8067 bytes 44 pkts (dropped 0, overlimits 0) > rate 712bit > lended: 44 borrowed: 0 giants: 0 > tokens: 432284 ctokens: 109555 > > class htb 1:30 parent 1:1 leaf 30: prio 2 rate 80000bit ceil 80000bit > burst 6Kb cburst 1699b > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > lended: 0 borrowed: 0 giants: 0 > tokens: 503316 ctokens: 139264 > > + exit > root@Devil:~ # sh -x wshaper.htb stop > + DOWNLINK=100 > + UPLINK=100 > + DEV=eth0 > + NOPRIOHOSTSRC= > + NOPRIOHOSTDST= > + NOPRIOPORTSRC= > + NOPRIOPORTDST= > + '[' stop = status ']' > + tc qdisc del dev eth0 root > + tc qdisc del dev eth0 ingress > + '[' stop = stop ']' > + exit > > root@Devil :~ # > > Don't think we generated enough uplink traffic to exercise the htb qdiscs. > > But it doesn't look like the ingress qdisc is working at all. > > I'm out of ideas for now. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD4DBQFFYiJDJ62kxkSCtLARAoCSAJiAi9VWPPNxy2q7NkH+pTvhSptbAJ930j0z KS/+8xz2JoVcSDm8taaDIA== =Jphi -----END PGP SIGNATURE----- |
|
From: Heiko Z. <he...@zu...> - 2006-11-20 21:42:15
|
On Mon, November 20, 2006 15:10, drew einhorn wrote: > Trying again. Hope I'm finally off the bogus email blacklist, and > this goes through. Your emails are arriving. It just looks like nobody is able to help you. :-( -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: drew e. <dre...@gm...> - 2006-11-20 21:17:23
|
Trying again. Hope I'm finally off the bogus email blacklist, and this goes through. ---------- Forwarded message ---------- From: drew einhorn <dre...@gm...> Date: Nov 19, 2006 11:51 PM Subject: Traffic Shaping on a Transparent Bridge not working! To: dev...@li... My first DL project was going well. Then I ran into problems attempting to shape my bandwidth. First I'll describe the parts that I believe are working correctly. I have a DL 1.2.11 box running the default kernel, 2.4.33.3-grsec I have br0 bridging all four ports eth0, eth1, eth2, eth3 on a quad port pci card. The bridge has not been assigned an ip number on the theory that this makes it much more difficult to attack. The bridge connects four devices on the 3bit public static ip block from my ISP. I have a single port ethernet pci card, eth4 with a static ip, on my internal private ip network. It is used for remote managent of the DL box from anywhere on my internal network. eth0 is connected to my ISP's router via the ethernet port on my ISDN modem. I know ISDN is a nearly dead technology, but it's the best thing my crappy telco offers. Tried a satellite ISP, but that's another long story. eth1 is connected to a hardened publicly accessible host. eth2 and eth3 are connected to the WAN ports on a couple of Linksys Cable/DSL routers. Eventually most of their functions will migrate to the DL box, but that is more than I wanted to bite off in my first DL project. The first Linksys box NATs one of my public ips to my internal private ip network. The second Linksys box is newer and includes a wireless access point used by a couple neighbors. It NATs a second public ip to a separate private ip network. All of the above appears to be working as expected. After pondering the mysteries of traffic shaping I decided to start with wondershaper 1.1a from lartc.org, rather than starting from scratch. Tried both the cbq and htb versions without any success. RTFM time. The htb section of http://lartc.org/howto/index.html is easier reading than the cbq section. And the howto claims htb is better anyway. Let's focus on the htb version of wondershaper. OK, First we edit wshaper.htb and configure the shell variables. Then we run: sh -x wshaper.htb to echo the commands as they are executed. Then we start pinging the router at the other end of the ISDN line. Then we start downloading a file to generate some traffic that really needs to be shaped. Then we run: sh -x wshaper.htb status to gather some statistics then we kill the download. then we sh -x wshaper.htb stop to shut down the malfunctioning shaper. Here's the output from the ping: $ ping 67.0.192.10 PING 67.0.192.10 (67.0.192.10) 56(84) bytes of data. Link is idle, normal ping times. 64 bytes from 67.0.192.10: icmp_seq=0 ttl=254 time=48.5 ms 64 bytes from 67.0.192.10: icmp_seq=1 ttl=254 time=48.4 ms 64 bytes from 67.0.192.10: icmp_seq=2 ttl=254 time=48.4 ms 64 bytes from 67.0.192.10: icmp_seq=3 ttl=254 time=48.4 ms 64 bytes from 67.0.192.10: icmp_seq=4 ttl=254 time= 48.5 ms 64 bytes from 67.0.192.10: icmp_seq=5 ttl=254 time=67.8 ms 64 bytes from 67.0.192.10: icmp_seq=6 ttl=254 time=48.3 ms 64 bytes from 67.0.192.10: icmp_seq=7 ttl=254 time=48.2 ms Download starts. Shaping is not working! Queues in router and/or ISDN modem grow, and ping times rapidly become huge. 64 bytes from 67.0.192.10: icmp_seq=8 ttl=254 time=184 ms 64 bytes from 67.0.192.10: icmp_seq=9 ttl=254 time=1080 ms 64 bytes from 67.0.192.10: icmp_seq=10 ttl=254 time=2025 ms 64 bytes from 67.0.192.10: icmp_seq=11 ttl=254 time=1551 ms 64 bytes from 67.0.192.10: icmp_seq=12 ttl=254 time=1078 ms 64 bytes from 67.0.192.10: icmp_seq=13 ttl=254 time=896 ms 64 bytes from 67.0.192.10: icmp_seq=14 ttl=254 time=1088 ms 64 bytes from 67.0.192.10: icmp_seq=15 ttl=254 time=1171 ms 64 bytes from 67.0.192.10: icmp_seq=16 ttl=254 time=1272 ms 64 bytes from 67.0.192.10: icmp_seq=17 ttl=254 time=1280 ms 64 bytes from 67.0.192.10: icmp_seq=18 ttl=254 time=1101 ms 64 bytes from 67.0.192.10: icmp_seq=19 ttl=254 time=1258 ms 64 bytes from 67.0.192.10: icmp_seq=20 ttl=254 time=1211 ms 64 bytes from 67.0.192.10: icmp_seq=21 ttl=254 time=1259 ms 64 bytes from 67.0.192.10: icmp_seq=22 ttl=254 time=1373 ms 64 bytes from 67.0.192.10: icmp_seq=23 ttl=254 time=1424 ms 64 bytes from 67.0.192.10: icmp_seq=24 ttl=254 time=1461 ms 64 bytes from 67.0.192.10: icmp_seq=25 ttl=254 time=1277 ms 64 bytes from 67.0.192.10: icmp_seq=26 ttl=254 time=1521 ms 64 bytes from 67.0.192.10: icmp_seq=27 ttl=254 time=1467 ms 64 bytes from 67.0.192.10: icmp_seq=28 ttl=254 time=1335 ms 64 bytes from 67.0.192.10: icmp_seq=29 ttl=254 time=1329 ms 64 bytes from 67.0.192.10: icmp_seq=30 ttl=254 time=1386 ms 64 bytes from 67.0.192.10: icmp_seq=31 ttl=254 time=1360 ms 64 bytes from 67.0.192.10: icmp_seq=32 ttl=254 time=1416 ms 64 bytes from 67.0.192.10: icmp_seq=33 ttl=254 time=1480 ms 64 bytes from 67.0.192.10: icmp_seq=34 ttl=254 time=1345 ms 64 bytes from 67.0.192.10: icmp_seq=35 ttl=254 time=1356 ms 64 bytes from 67.0.192.10: icmp_seq=36 ttl=254 time=1370 ms 64 bytes from 67.0.192.10: icmp_seq=37 ttl=254 time=1278 ms 64 bytes from 67.0.192.10: icmp_seq=38 ttl=254 time=1612 ms 64 bytes from 67.0.192.10: icmp_seq=39 ttl=254 time=1520 ms 64 bytes from 67.0.192.10: icmp_seq=40 ttl=254 time=1322 ms 64 bytes from 67.0.192.10: icmp_seq=41 ttl=254 time=1545 ms Kill the download queues empty and ping times return to normal 64 bytes from 67.0.192.10 : icmp_seq=42 ttl=254 time=975 ms 64 bytes from 67.0.192.10: icmp_seq=43 ttl=254 time=67.4 ms 64 bytes from 67.0.192.10: icmp_seq=44 ttl=254 time= 73.6 ms 64 bytes from 67.0.192.10: icmp_seq=45 ttl=254 time=45.2 ms 64 bytes from 67.0.192.10: icmp_seq=46 ttl=254 time=45.2 ms 64 bytes from 67.0.192.10: icmp_seq=47 ttl=254 time=44.8 ms And, here's the shell commands and their output: root@Devil:~ # sh -x wshaper.htb + DOWNLINK=100 + UPLINK=100 + DEV=eth0 + NOPRIOHOSTSRC= + NOPRIOHOSTDST= + NOPRIOPORTSRC= + NOPRIOPORTDST= + '[' '' = status ']' + tc qdisc del dev eth0 root + tc qdisc del dev eth0 ingress + '[' '' = stop ']' + tc qdisc add dev eth0 root handle 1: htb default 20 + tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbit burst 6k + tc class add dev eth0 parent 1:1 classid 1:10 htb rate 100kbit burst 6k prio 1 + tc class add dev eth0 parent 1:1 classid 1:20 htb rate 90kbit burst 6k prio 2 + tc class add dev eth0 parent 1:1 classid 1:30 htb rate 80kbit burst 6k prio 2 + tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 + tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 + tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10 + tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip tos 0x10 0xff flowid 1:10 + tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip protocol 1 0xff flowid 1:10 + tc filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:10 + tc filter add dev eth0 parent 1: protocol ip prio 18 u32 match ip dst 0.0.0.0/0 flowid 1:20 + tc qdisc add dev eth0 handle ffff: ingress + tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 100kbit burst 10k drop flowid :1 root@Devil:~ # sh -x wshaper.htb status + DOWNLINK=100 + UPLINK=100 + DEV=eth0 + NOPRIOHOSTSRC= + NOPRIOHOSTDST= + NOPRIOPORTSRC= + NOPRIOPORTDST= + '[' status = status ']' + tc -s qdisc ls dev eth0 qdisc htb 1: r2q 10 default 20 direct_packets_stat 0 Sent 18649 bytes 191 pkts (dropped 0, overlimits 0) qdisc sfq 10: parent 1:10 limit 128p quantum 1514b perturb 10sec Sent 10582 bytes 147 pkts (dropped 0, overlimits 0) qdisc sfq 20: parent 1:20 limit 128p quantum 1514b perturb 10sec Sent 8067 bytes 44 pkts (dropped 0, overlimits 0) qdisc sfq 30: parent 1:30 limit 128p quantum 1514b perturb 10sec Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc ingress ffff: ---------------- Sent 0 bytes 0 pkts (dropped 0, overlimits 0) + tc -s class ls dev eth0 class htb 1:1 root rate 100000bit ceil 100000bit burst 6Kb cburst 1724b Sent 18649 bytes 191 pkts (dropped 0, overlimits 0) rate 1320bit 1pps lended: 0 borrowed: 0 giants: 0 tokens: 398459 ctokens: 108855 class htb 1:10 parent 1:1 leaf 10: prio 1 rate 100000bit ceil 100000bit burst 6Kb cburst 1724b Sent 10582 bytes 147 pkts (dropped 0, overlimits 0) rate 656bit 1pps lended: 147 borrowed: 0 giants: 0 tokens: 398459 ctokens: 108855 class htb 1:20 parent 1:1 leaf 20: prio 2 rate 90000bit ceil 90000bit burst 6Kb cburst 1711b Sent 8067 bytes 44 pkts (dropped 0, overlimits 0) rate 712bit lended: 44 borrowed: 0 giants: 0 tokens: 432284 ctokens: 109555 class htb 1:30 parent 1:1 leaf 30: prio 2 rate 80000bit ceil 80000bit burst 6Kb cburst 1699b Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 503316 ctokens: 139264 + exit root@Devil:~ # sh -x wshaper.htb stop + DOWNLINK=100 + UPLINK=100 + DEV=eth0 + NOPRIOHOSTSRC= + NOPRIOHOSTDST= + NOPRIOPORTSRC= + NOPRIOPORTDST= + '[' stop = status ']' + tc qdisc del dev eth0 root + tc qdisc del dev eth0 ingress + '[' stop = stop ']' + exit root@Devil :~ # Don't think we generated enough uplink traffic to exercise the htb qdiscs. But it doesn't look like the ingress qdisc is working at all. I'm out of ideas for now. -- Drew Einhorn -- Drew Einhorn |
|
From: drew e. <dre...@gm...> - 2006-11-20 16:35:05
|
Arghh! Think I'm off the bogus antispam blacklist. Hope this goes through this time. On 11/19/06, drew einhorn <dre...@gm...> wrote: > My first DL project was going well. Then I ran into problems attempting > to shape my bandwidth. > > First I'll describe the parts that I believe are working correctly. > > I have a DL 1.2.11 box running the default kernel, 2.4.33.3-grsec > > I have br0 bridging all four ports eth0, eth1, eth2, eth3 on a quad port > pci card. The bridge has not been assigned an ip number on the theory > that this makes it much more difficult to attack. The bridge connects > four devices on the 3bit public static ip block from my ISP. > > I have a single port ethernet pci card, eth4 with a static ip, on my > internal private ip network. It is used for remote managent of the DL > box from anywhere on my internal network. > > eth0 is connected to my ISP's router via the ethernet port on my > ISDN modem. I know ISDN is a nearly dead technology, but it's the best > thing my crappy telco offers. Tried a satellite ISP, but that's another > long story. > > eth1 is connected to a hardened publicly accessible host. > > eth2 and eth3 are connected to the WAN ports on a couple of Linksys > Cable/DSL routers. Eventually most of their functions will migrate to the > DL box, but that is more than I wanted to bite off in my first DL project. > > The first Linksys box NATs one of my public ips to my internal private > ip network. The second Linksys box is newer and includes a wireless > access point used by a couple neighbors. It NATs a second public ip to > a separate private ip network. > > All of the above appears to be working as expected. > > After pondering the mysteries of traffic shaping I decided to start with > wondershaper 1.1a from lartc.org, rather than starting from scratch. > > Tried both the cbq and htb versions without any success. > > RTFM time. The htb section of > http://lartc.org/howto/index.html is easier > reading than the cbq section. And the howto claims htb is better anyway. > Let's focus on the htb version of wondershaper. > > OK, First we edit wshaper.htb and configure the shell variables. Then we > run: sh -x wshaper.htb > to echo the commands as they are executed. > > Then we start pinging the router at the other end of the ISDN line. > > Then we start downloading a file to generate some traffic that really > needs to be shaped. > > Then we run: sh -x wshaper.htb status > to gather some statistics > > then we kill the download. > > then we sh -x wshaper.htb stop to shut down the malfunctioning shaper. > > Here's the output from the ping: > > $ ping 67.0.192.10 > PING 67.0.192.10 (67.0.192.10) 56(84) bytes of data. > > Link is idle, normal ping times. > > 64 bytes from 67.0.192.10: icmp_seq=0 ttl=254 time=48.5 ms > 64 bytes from 67.0.192.10: icmp_seq=1 ttl=254 time=48.4 ms > 64 bytes from 67.0.192.10: icmp_seq=2 ttl=254 time=48.4 ms > 64 bytes from 67.0.192.10: icmp_seq=3 ttl=254 time=48.4 ms > 64 bytes from 67.0.192.10: icmp_seq=4 ttl=254 time= 48.5 ms > 64 bytes from 67.0.192.10: icmp_seq=5 ttl=254 time=67.8 ms > 64 bytes from 67.0.192.10: icmp_seq=6 ttl=254 time=48.3 ms > 64 bytes from 67.0.192.10: icmp_seq=7 ttl=254 time=48.2 ms > > Download starts. Shaping is not working! Queues in > router and/or ISDN modem grow, and ping times rapidly > become huge. > > 64 bytes from 67.0.192.10: icmp_seq=8 ttl=254 time=184 ms > 64 bytes from 67.0.192.10: icmp_seq=9 ttl=254 time=1080 ms > 64 bytes from 67.0.192.10: icmp_seq=10 ttl=254 time=2025 ms > 64 bytes from 67.0.192.10: icmp_seq=11 ttl=254 time=1551 ms > 64 bytes from 67.0.192.10: icmp_seq=12 ttl=254 time=1078 ms > 64 bytes from 67.0.192.10: icmp_seq=13 ttl=254 time=896 ms > 64 bytes from 67.0.192.10: icmp_seq=14 ttl=254 time=1088 ms > 64 bytes from 67.0.192.10: icmp_seq=15 ttl=254 time=1171 ms > 64 bytes from 67.0.192.10: icmp_seq=16 ttl=254 time=1272 ms > 64 bytes from 67.0.192.10: icmp_seq=17 ttl=254 time=1280 ms > 64 bytes from 67.0.192.10: icmp_seq=18 ttl=254 time=1101 ms > 64 bytes from 67.0.192.10: icmp_seq=19 ttl=254 time=1258 ms > 64 bytes from 67.0.192.10: icmp_seq=20 ttl=254 time=1211 ms > 64 bytes from 67.0.192.10: icmp_seq=21 ttl=254 time=1259 ms > 64 bytes from 67.0.192.10: icmp_seq=22 ttl=254 time=1373 ms > 64 bytes from 67.0.192.10: icmp_seq=23 ttl=254 time=1424 ms > 64 bytes from 67.0.192.10: icmp_seq=24 ttl=254 time=1461 ms > 64 bytes from 67.0.192.10: icmp_seq=25 ttl=254 time=1277 ms > 64 bytes from 67.0.192.10: icmp_seq=26 ttl=254 time=1521 ms > 64 bytes from 67.0.192.10: icmp_seq=27 ttl=254 time=1467 ms > 64 bytes from 67.0.192.10: icmp_seq=28 ttl=254 time=1335 ms > 64 bytes from 67.0.192.10: icmp_seq=29 ttl=254 time=1329 ms > 64 bytes from 67.0.192.10: icmp_seq=30 ttl=254 time=1386 ms > 64 bytes from 67.0.192.10: icmp_seq=31 ttl=254 time=1360 ms > 64 bytes from 67.0.192.10: icmp_seq=32 ttl=254 time=1416 ms > 64 bytes from 67.0.192.10: icmp_seq=33 ttl=254 time=1480 ms > 64 bytes from 67.0.192.10: icmp_seq=34 ttl=254 time=1345 ms > 64 bytes from 67.0.192.10: icmp_seq=35 ttl=254 time=1356 ms > 64 bytes from 67.0.192.10: icmp_seq=36 ttl=254 time=1370 ms > 64 bytes from 67.0.192.10: icmp_seq=37 ttl=254 time=1278 ms > 64 bytes from 67.0.192.10: icmp_seq=38 ttl=254 time=1612 ms > 64 bytes from 67.0.192.10: icmp_seq=39 ttl=254 time=1520 ms > 64 bytes from 67.0.192.10: icmp_seq=40 ttl=254 time=1322 ms > 64 bytes from 67.0.192.10: icmp_seq=41 ttl=254 time=1545 ms > > Kill the download queues empty and ping times return to normal > > 64 bytes from 67.0.192.10 : icmp_seq=42 ttl=254 time=975 ms > 64 bytes from 67.0.192.10: icmp_seq=43 ttl=254 time=67.4 ms > 64 bytes from 67.0.192.10: icmp_seq=44 ttl=254 time= 73.6 ms > 64 bytes from 67.0.192.10: icmp_seq=45 ttl=254 time=45.2 ms > 64 bytes from 67.0.192.10: icmp_seq=46 ttl=254 time=45.2 ms > 64 bytes from 67.0.192.10: icmp_seq=47 ttl=254 time=44.8 ms > > > And, here's the shell commands and their output: > > root@Devil:~ # sh -x wshaper.htb > + DOWNLINK=100 > + UPLINK=100 > + DEV=eth0 > + NOPRIOHOSTSRC= > + NOPRIOHOSTDST= > + NOPRIOPORTSRC= > + NOPRIOPORTDST= > + '[' '' = status ']' > + tc qdisc del dev eth0 root > + tc qdisc del dev eth0 ingress > + '[' '' = stop ']' > + tc qdisc add dev eth0 root handle 1: htb default 20 > + tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbit burst 6k > + tc class add dev eth0 parent 1:1 classid 1:10 htb rate 100kbit burst 6k > prio 1 > + tc class add dev eth0 parent 1:1 classid 1:20 htb rate 90kbit burst 6k > prio 2 > + tc class add dev eth0 parent 1:1 classid 1:30 htb rate 80kbit burst 6k > prio 2 > + tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 > + tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 > + tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10 > + tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip tos > 0x10 0xff flowid 1:10 > + tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip > protocol 1 0xff flowid 1:10 > + tc filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip protocol > 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 > 0xff at 33 flowid 1:10 > + tc filter add dev eth0 parent 1: protocol ip prio 18 u32 match ip dst > 0.0.0.0/0 flowid 1:20 > + tc qdisc add dev eth0 handle ffff: ingress > + tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip src > 0.0.0.0/0 police rate 100kbit burst 10k drop flowid :1 > > > root@Devil:~ # sh -x wshaper.htb status > + DOWNLINK=100 > + UPLINK=100 > + DEV=eth0 > + NOPRIOHOSTSRC= > + NOPRIOHOSTDST= > + NOPRIOPORTSRC= > + NOPRIOPORTDST= > + '[' status = status ']' > + tc -s qdisc ls dev eth0 > qdisc htb 1: r2q 10 default 20 direct_packets_stat 0 > Sent 18649 bytes 191 pkts (dropped 0, overlimits 0) > qdisc sfq 10: parent 1:10 limit 128p quantum 1514b perturb 10sec > Sent 10582 bytes 147 pkts (dropped 0, overlimits 0) > qdisc sfq 20: parent 1:20 limit 128p quantum 1514b perturb 10sec > Sent 8067 bytes 44 pkts (dropped 0, overlimits 0) > qdisc sfq 30: parent 1:30 limit 128p quantum 1514b perturb 10sec > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > qdisc ingress ffff: ---------------- > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > + tc -s class ls dev eth0 > class htb 1:1 root rate 100000bit ceil 100000bit burst 6Kb cburst 1724b > Sent 18649 bytes 191 pkts (dropped 0, overlimits 0) > rate 1320bit 1pps > lended: 0 borrowed: 0 giants: 0 > tokens: 398459 ctokens: 108855 > > class htb 1:10 parent 1:1 leaf 10: prio 1 rate 100000bit ceil 100000bit > burst 6Kb cburst 1724b > Sent 10582 bytes 147 pkts (dropped 0, overlimits 0) > rate 656bit 1pps > lended: 147 borrowed: 0 giants: 0 > tokens: 398459 ctokens: 108855 > > class htb 1:20 parent 1:1 leaf 20: prio 2 rate 90000bit ceil 90000bit burst > 6Kb cburst 1711b > Sent 8067 bytes 44 pkts (dropped 0, overlimits 0) > rate 712bit > lended: 44 borrowed: 0 giants: 0 > tokens: 432284 ctokens: 109555 > > class htb 1:30 parent 1:1 leaf 30: prio 2 rate 80000bit ceil 80000bit burst > 6Kb cburst 1699b > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > lended: 0 borrowed: 0 giants: 0 > tokens: 503316 ctokens: 139264 > > + exit > root@Devil:~ # sh -x wshaper.htb stop > + DOWNLINK=100 > + UPLINK=100 > + DEV=eth0 > + NOPRIOHOSTSRC= > + NOPRIOHOSTDST= > + NOPRIOPORTSRC= > + NOPRIOPORTDST= > + '[' stop = status ']' > + tc qdisc del dev eth0 root > + tc qdisc del dev eth0 ingress > + '[' stop = stop ']' > + exit > > root@Devil :~ # > > Don't think we generated enough uplink traffic to exercise the htb qdiscs. > > But it doesn't look like the ingress qdisc is working at all. > > I'm out of ideas for now. > > -- > Drew Einhorn -- Drew Einhorn |
|
From: Bruce S. <bw...@ar...> - 2006-11-20 14:56:58
|
>> Do either of those packages start by _default_ when you boot DL? >> > > Yes. Any program/script placed in /etc/cron.daily for example will be executed > as root. So far as I know this is the only way aide is executed. Had aide > install been good then everybody would be running it whether they wanted to or > not. There's a thing called logwatch also arrived in this DL version which does > work. It is also started in cron.daily. First I knew about it was its report > in my inbox. > OK, maybe the line in the crontab should be commented out by default. (I'll leave that decision to Heiko) OTOH, the last time I checked, crond itself doesn't start by default. And if/when you turn on cron, you it's a good idea to edit/check the crontabs. - BS |
|
From: Dick M. <di...@li...> - 2006-11-20 14:32:22
|
Bruce Smith wrote: >>>> Whilst these are minor irritants it does bother me that things are being added >>>> to the system without proper auditing. This is supposed to be a secure system >>>> and addition of unverified software obviously gives an opportunity for malware >>>> to be unwittingly installed. >>> Can you be more specific about what unverified software you're referring to? >> aide and awstats. > > How do you suggest we audit them? Do you expect us to go through the > source code line by line? These things are always difficult. I suppose just trying it out might be a good start. If you've worked with it and configured it to suit DL organisation then you'll know what it comprises. > (We'll get back to you in about 50 years, as > soon as we're done with the kernel :) :-) > Or can we trust other sources to audit them? That's up to you. We trust you, we have to and we want to. > Personally I didn't add them, and I've never used either of those > packages. Quite. The fact that aide doesn't work tells a story. > Do either of those packages start by _default_ when you boot DL? Yes. Any program/script placed in /etc/cron.daily for example will be executed as root. So far as I know this is the only way aide is executed. Had aide install been good then everybody would be running it whether they wanted to or not. There's a thing called logwatch also arrived in this DL version which does work. It is also started in cron.daily. First I knew about it was its report in my inbox. > If so, then you _may_ be correct that there is a problem. > What evidence do you have that either of those packages are malware? I hope there isn't any. Dick |
|
From: Dr. A. B. <be...@ec...> - 2006-11-20 13:59:28
|
> Dick Middleton wrote: > > The recently added aide is broken. It's obviously copied from > Debian and some needed parts don't exist (such as /var/lib/aide, > /etc/default, tempfile command and others). That's all very well > except the script in /etc/cron.daily exists and fails. Firstly it > fails because it doesn't have execute permission and secondly it > fails because programs and directories it references don't exist. > > The recently added awstats is also broken for a similar reason. > The script in cron.daily doesn't have execute permissions. I've not > tried to run this but I notice various files with 1980 timestamps > such as the aforementioned and /etc/awstats/awstats.model.conf. The time for test build/install/running/debug when the software is update is not enough. I added Aide and Awstats, in my personal distribution, about a year ago and the inclusion in devil-linux is May. Perhaps the Debian patch has modified something. Today I sent script update (and work) to Heiko for inclusion in CVS and next release. Now, Awstats (awstats.sourceforge.net) is a log analizer and you MUST edit configuration for YOUR system (my apache logs are in /chroot/var/lib/httpd and your?) and awstats.model.conf is a template config. Check http://econtools.economia.unife.it/devil-linux for other information. ALL file in /etc are 1980 timestamps > Whilst these are minor irritants it does bother me that things are > being added to the system without proper auditing. This is supposed > to be a secure system and addition of unverified software obviously > gives an opportunity for malware to be unwittingly installed. Untested maybe, unverified software ?!? for malware ?!? Argh..... maybe Ubuntu installation has security problems! Alberto +--------------------------+ | Dott. Alberto Benati | | System Administrator | | Faculty of Economics | | University of Ferrara | | be...@ec... | | Tel: +39 0532 45 5012 | +--------------------------+ |
|
From: Bruce S. <bw...@ar...> - 2006-11-20 13:02:21
|
> >> Whilst these are minor irritants it does bother me that things are being added > >> to the system without proper auditing. This is supposed to be a secure system > >> and addition of unverified software obviously gives an opportunity for malware > >> to be unwittingly installed. > > > > Can you be more specific about what unverified software you're referring to? > > aide and awstats. How do you suggest we audit them? Do you expect us to go through the source code line by line? (We'll get back to you in about 50 years, as soon as we're done with the kernel :) Or can we trust other sources to audit them? Some place that actually understands the source code perhaps? How about Novell/SuSE? Both of those packages are included with SuSE 10.1. Personally I didn't add them, and I've never used either of those packages. Hell, I didn't even know what those packages are until I searched my SuSE 10.1 DVD to see if they exist there. Do either of those packages start by _default_ when you boot DL? If so, then you _may_ be correct that there is a problem. Otherwise even malware won't hurt you if it never runs. You should know a little about the packages you designate to start at boot. What evidence do you have that either of those packages are malware? - BS |
|
From: Bruce S. <bw...@ar...> - 2006-11-20 12:49:04
|
> Apparently this list has been using a bogus blacklist. > My mail to the list has been silently disappearing into a blackhole > for the past week or so. > > Finally I discovered > http://www.mxtoolbox.com/blacklists.aspx?AG=GBL&gclid=CI7gntKM1YgCFQR8VAod9FJsZg > > It told I was on the http://www.moensted.dk/spam/no-more-funn/ > blacklist because netblk-q0228-65-125-188-0 is home to spammers. > > This makes no sense. My ip 209.181.116.109 is not even in that > netblock! > > Fortunately the automated whitelist tool promptly removed me from the > blacklist. So you should see this email. > > Or maybe I have to wait a while longer for your dns cache to expire. > > Arghhhhhh! > > Please discontinue using this buggy blacklist! There are a lot of problems with blacklists in general, and I would love to discontinue using it, but it's out of our control. Sourceforge hosts our mailing lists. I recommend you complain to sourceforge. Let us know their response. - BS |
|
From: Dick M. <di...@li...> - 2006-11-20 12:46:58
|
Bruce Smith wrote: >> Whilst these are minor irritants it does bother me that things are being added >> to the system without proper auditing. This is supposed to be a secure system >> and addition of unverified software obviously gives an opportunity for malware >> to be unwittingly installed. > > Can you be more specific about what unverified software you're referring to? aide and awstats. Dick |
50 messages has been excluded from this view by a project administrator.
