To implement RFC 5848 (Signed Syslog Messages)?
Hi, hackers: Red Hat's star developer, Lennart Poettering, is porting Windows Event Log to GNU/Linux :) https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTspli=1 Regardless of his stupid arguments, let's talk about something trivial. How about to implement RFC 5848 in our syslogd? It adds the encryption to the existing syslog message layer, and increase the security in transferring. http://tools.ietf.org/html/rfc5848 Albert Mietus made a nice presentation in 2002 http://www.slideshare.net/SoftwareBeterMaken.nl/securing-syslog-on-freebsd Not sure whether his code is accessible or not. -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: To implement RFC 5848 (Signed Syslog Messages)?
On Thu, Dec 1, 2011 at 1:01 AM, Zhihao Yuan lich...@gmail.com wrote: Hi, hackers: Red Hat's star developer, Lennart Poettering, is porting Windows Event Log to GNU/Linux :) https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTspli=1 Regardless of his stupid arguments, let's talk about something trivial. How about to implement RFC 5848 in our syslogd? It adds the encryption to the existing syslog message layer, and increase the security in transferring. http://tools.ietf.org/html/rfc5848 Albert Mietus made a nice presentation in 2002 http://www.slideshare.net/SoftwareBeterMaken.nl/securing-syslog-on-freebsd Not sure whether his code is accessible or not. I agree that encryption and tcp (reliable) transport of logs should be a must for syslogd in FreeBSD. It's going to be interesting how things with Lennart's 'journald' play out -- without defining an industry standard for how messages are presented and categorized, I predict that things will turn into a mess (I could be proved wrong, but given past experience, this is how things evolve unless framework adoption lags standardization). Thanks :), -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Invalid memory stats from vmstat and sysctl vm.vmtotal?
- Original Message - From: Jason Hellenthal jh...@dataix.net This goes along with the thoughts I had about 4 months ago tending to some zfs statistics as well top showing greater than 100% actual CPU usage. This is a big pet peave of mine. Its like saying you ate 134% of a bannanna when in all reallity it is impossible. You can never have more than 100% usage of anything and when seen is a clear notice that some math is considerably incorrect leading to other such miscalculations to be performed. Things like the above already have checks in place that ensure no boundries are being crossed/overflowed or underrun but it surely makes processing results building future products a bitch. One instance is the calculation of threads for example firefox can be seen using upto or more 338% of the CPU. Thats impossible its like saying anyones CPU grew by 400%. I could understand a bit of overflow as stats are snapshots which may not be instuntanious, but 31GB instead of under 8GB is hardly a rounding issue / overflow. With respect to top showing greater than 100% by how much are you talking? Do your realise that each core = 100%? So if you have a quad core your system total will be 400% not 100%? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Invalid memory stats from vmstat and sysctl vm.vmtotal?
On 12/1/11 11:44 AM, Steven Hartland wrote: - Original Message - From: Jason Hellenthal jh...@dataix.net This goes along with the thoughts I had about 4 months ago tending to some zfs statistics as well top showing greater than 100% actual CPU usage. This is a big pet peave of mine. Its like saying you ate 134% of a bannanna when in all reallity it is impossible. You can never have more than 100% usage of anything and when seen is a clear notice that some math is considerably incorrect leading to other such miscalculations to be performed. Things like the above already have checks in place that ensure no boundries are being crossed/overflowed or underrun but it surely makes processing results building future products a bitch. One instance is the calculation of threads for example firefox can be seen using upto or more 338% of the CPU. Thats impossible its like saying anyones CPU grew by 400%. I could understand a bit of overflow as stats are snapshots which may not be instuntanious, but 31GB instead of under 8GB is hardly a rounding issue / overflow. With respect to top showing greater than 100% by how much are you talking? Do your realise that each core = 100%? So if you have a quad core your system total will be 400% not 100%? That's his point, you cannot use 400% of a system as a whole, his point is that top should report 100% where each core accounts for 25% ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Invalid memory stats from vmstat and sysctl vm.vmtotal?
- Original Message - From: Damien Fleuriot m...@my.gd I could understand a bit of overflow as stats are snapshots which may not be instuntanious, but 31GB instead of under 8GB is hardly a rounding issue / overflow. With respect to top showing greater than 100% by how much are you talking? Do your realise that each core = 100%? So if you have a quad core your system total will be 400% not 100%? That's his point, you cannot use 400% of a system as a whole, his point is that top should report 100% where each core accounts for 25% Then I would have to disagree, keeping 100% to mean 100% of a single core is much easier to manage than 100% of a machines total capacity. If you went to 100% = the machine total capacity processes could be using a lot of cpu without even registering 1% on today's machines where 24 cores is common place. It also makes detecting single process / thread bottlenecks easier as if your seeing 100% you know its maxing a core, instead of having to calculate it once you know how many cores the machine has. If your looking for total machine usage then that's also their in the summary at the top of the screen e.g. CPU states: 13.6% user, 0.0% nice, 1.3% system, 0.0% interrupt, 85.1% idle Anyway this is quite off topic, and I don't want to loose sight of the threads goal which is to determine why we can see 31GB of usage on an 8GB machine with very little shared memory usage an no swap usage. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Invalid memory stats from vmstat and sysctl vm.vmtotal?
On Wed, 30 Nov 2011 12:39:10 - Steven Hartland wrote: We're seeing some impossible memory usage stats reported on machines here from vmstat and sysctl vm.vmtotal. We have machines reporting to be using 31GB total when they only have 8GB physical and are not using any swap. Here's an output from one of our machines:- vmstat -c 2 -w 1 -n 0 procs memory page faults cpu r b w avmfre flt re pi pofr sr in sy cs us sy id 0 0 0 31768M 2112M 586 0 0 0 421 0 106 270 569 0 6 94 0 0 0 31768M 2112M 2 0 0 0 0 0 370 8139 3996 0 1 99 ... It looks like it may be out by a factor of 4, possibly due to the fact the its a 4k page size not 1k as indicated by the vmstat man page:- I don't think so, I have 16GB and tops shows: Mem: 817M Active, 396M Inact, 1364M Wired, 82M Cache, 1282M Buf, 13G Free but vmstat -c 2 -w 1 -n 0 procs memory page faults cpu r b w avmfre flt re pi pofr sr in sy cs us sy id 0 0 0 9750M13G 450 5 3 1 560 0 234 50201 5206 2 2 96 1 0 0 9742M13G79 4 0 0 573 0 239 51886 4700 0 1 99 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sysctl description spillover and also setting the sysctl ?
On Wednesday, November 30, 2011 1:48:15 pm Jason Hellenthal wrote: On Wed, Nov 30, 2011 at 11:52:46AM -0500, John Baldwin wrote: On Friday, November 25, 2011 2:36:30 am Jason Hellenthal wrote: Found a troubling result of the following and figured someone might want to take a look. Pay close attention to the output and behavior. sysctl net.inet.udp.blackhole=0 sysctl net.inet.udp.blackhole sysctl -d net.inet.udp.blackhole=1 sysctl net.inet.udp.blackhole Is this expected ? should it not just display the description instead of adjusting ? as well not display the description like it is adjusting the description too ? Hah, cute. It should probably fail with an error if you do something like that, yes. Yeah thats what I thought about it to but the more I thought about it, if it just displayed the values changing instead of the description when =N is supplied I think that would be acceptable to. 0 - 1 in this case. Or possibly sys.oid: 0 - 1 # Description since sysctl.conf(5) also takes comments like that. Not really thats something at the top of the list for fixes though. Low fruit. Food for thought. I think it's simplest to just make -d force descriptions only and ignore settings. I've committed a one-line fix to sysctl(8) for that. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Invalid memory stats from vmstat and sysctl vm.vmtotal?
- Original Message - From: RW rwmailli...@googlemail.com To: freebsd-hackers@freebsd.org Sent: Thursday, December 01, 2011 1:58 PM Subject: Re: Invalid memory stats from vmstat and sysctl vm.vmtotal? On Wed, 30 Nov 2011 12:39:10 - Steven Hartland wrote: We're seeing some impossible memory usage stats reported on machines here from vmstat and sysctl vm.vmtotal. We have machines reporting to be using 31GB total when they only have 8GB physical and are not using any swap. Here's an output from one of our machines:- vmstat -c 2 -w 1 -n 0 procs memory page faults cpu r b w avmfre flt re pi pofr sr in sy cs us sy id 0 0 0 31768M 2112M 586 0 0 0 421 0 106 270 569 0 6 94 0 0 0 31768M 2112M 2 0 0 0 0 0 370 8139 3996 0 1 99 ... It looks like it may be out by a factor of 4, possibly due to the fact the its a 4k page size not 1k as indicated by the vmstat man page:- I don't think so, I have 16GB and tops shows: Mem: 817M Active, 396M Inact, 1364M Wired, 82M Cache, 1282M Buf, 13G Free but vmstat -c 2 -w 1 -n 0 procs memory page faults cpu r b w avmfre flt re pi pofr sr in sy cs us sy id 0 0 0 9750M13G 450 5 3 1 560 0 234 50201 5206 2 2 96 1 0 0 9742M13G79 4 0 0 573 0 239 51886 4700 0 1 99 Hmm, yes on another machine same OS with 16GB memory we see:- dmesg | grep memory real memory = 17179869184 (16384 MB) avail memory = 16536604672 (15770 MB) vmstat -c 2 -w 1 -n 0 procs memory page faults cpu r b w avmfre flt re pi pofr sr in sy cs us sy id 0 0 0 1948M 666M 395 14 0 0 398 1966 3237 5980 14085 2 4 93 1 0 0 1948M 636M 4 0 0 016 0 8215 18660 35322 2 7 92 sysctl vm.vmtotal vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) === Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 194) Virtual Memory: (Total: 1075975332K Active: 1979056K) Real Memory:(Total: 309048K Active: 160804K) Shared Virtual Memory: (Total: 75112K Active: 18860K) Shared Real Memory: (Total: 15656K Active: 10572K) Free Memory Pages: 731960K but with top:- last pid: 38187; load averages: 0.15, 0.16, 0.16 up 2+23:33:55 15:13:02 195 processes: 1 running, 194 sleeping CPU: 0.0% user, 0.0% nice, 4.1% system, 0.0% interrupt, 95.9% idle Mem: 886M Active, 12G Inact, 2194M Wired, 599M Cache, 1630M Buf, 138M Free Swap: 8192M Total, 1512K Used, 8190M Free So I've no idea whats going on? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Invalid memory stats from vmstat and sysctl vm.vmtotal?
On Thu, Dec 01, 2011 at 10:44:58AM -, Steven Hartland wrote: - Original Message - From: Jason Hellenthal jh...@dataix.net This goes along with the thoughts I had about 4 months ago tending to some zfs statistics as well top showing greater than 100% actual CPU usage. This is a big pet peave of mine. Its like saying you ate 134% of a bannanna when in all reallity it is impossible. You can never have more than 100% usage of anything and when seen is a clear notice that some math is considerably incorrect leading to other such miscalculations to be performed. Things like the above already have checks in place that ensure no boundries are being crossed/overflowed or underrun but it surely makes processing results building future products a bitch. One instance is the calculation of threads for example firefox can be seen using upto or more 338% of the CPU. Thats impossible its like saying anyones CPU grew by 400%. I could understand a bit of overflow as stats are snapshots which may not be instuntanious, but 31GB instead of under 8GB is hardly a rounding issue / overflow. I agree With respect to top showing greater than 100% by how much are you talking? Do your realise that each core = 100%? So if you have a quad core your system total will be 400% not 100%? Yeah I realize that but it still would lead you to believe that if a proccessor has 4 cores on the same die then total for each core could only be 25% usage. And the usage for a proccess only consuming full usage of 1 core is 100%. But you can start firefox on a single uniproccessor and like stated above see large usage percents near 338% or greater which is impossible and leads me to believe were forcing calculation for the entire proccess of threads onto tthread 0. This makes accounting pretty difficult. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
DiffServ SNMP agent
Hello, I wonder people would know if there is diffserv SNMP agent implementation for FreeBSD that is available? Googled a bit, but was not too successful in finding. Thanks in advance! Alan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Invalid memory stats from vmstat and sysctl vm.vmtotal?
On Thu, Dec 01, 2011 at 01:23:35PM -, Steven Hartland wrote: - Original Message - From: Damien Fleuriot m...@my.gd I could understand a bit of overflow as stats are snapshots which may not be instuntanious, but 31GB instead of under 8GB is hardly a rounding issue / overflow. With respect to top showing greater than 100% by how much are you talking? Do your realise that each core = 100%? So if you have a quad core your system total will be 400% not 100%? That's his point, you cannot use 400% of a system as a whole, his point is that top should report 100% where each core accounts for 25% Then I would have to disagree, keeping 100% to mean 100% of a single core is much easier to manage than 100% of a machines total capacity. If you went to 100% = the machine total capacity processes could be using a lot of cpu without even registering 1% on today's machines where 24 cores is common place. It also makes detecting single process / thread bottlenecks easier as if your seeing 100% you know its maxing a core, instead of having to calculate it once you know how many cores the machine has. If your looking for total machine usage then that's also their in the summary at the top of the screen e.g. CPU states: 13.6% user, 0.0% nice, 1.3% system, 0.0% interrupt, 85.1% idle Anyway this is quite off topic, and I don't want to loose sight of the threads goal which is to determine why we can see 31GB of usage on an 8GB machine with very little shared memory usage an no swap usage. Just to put some visuals to this... . `-- DIE |-- Core1 [Idle] |-- Core2 [35% ] | `-- thread127 |-- Core3 [40% ] | `-- thread127 `-- Core4 [100%] `-- thread127 In this case you would say the DIE should be at a total of 175% ? $(((25*0)+(25*0.35)+(25*0.40)+(25*1.00))) Out of sanity and each core only being 25% of the total DIE it should be reporting. It is using all together 43.75% of the total DIE. But thats not what I see even on SP machines. 1 DIE 1 core and a report of 338% usage for 8 threads of firefox. If someone was attempting to write a scheduler to launch processes yield back to the scheduler to launch more based on processor usage either by core or by die totals that scheduler would be ineffective at best without alot of kludges put in place to handle all the misinterpretation. Somewhere along the line our math has been distorted or the move from SP - MP, cores, hyperthreading etc.. has just not completed yet and should not be ignored. pgpqrrUzEGGAL.pgp Description: PGP signature
Re: Invalid memory stats from vmstat and sysctl vm.vmtotal?
.. where are these statistics coming from? top? Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
