Re: [Observium] SVN commit comments, overall usability of SVN code
You can get a refund from the front desk.
Adam.
Sebastian Wiesinger observium@ml.karotte.org wrote:
Hello,
I'm testing out Observium and I like a lot of the things that Observium does. But what really irks me is the way and style of releasing new versions and committing to the SVN repository.
- Commit messages. To quickly get a feel what changed between
revisions I consult the svn log. That is the primary source of information. In the Observium SVN this often leads me to read things like this:
r4147 - CODE, Y U NO LOOK RITE r4140 - Me need your soul, more souls. >:-> r4139 - you're not ready for this. :) r4125 - disable whatever the fuck that is r4101 - add some crappy errors
And on and on.
Things like that make me question the code quality that is committed to the repository. What kind of project do you want to be with these kind of commit messages? Mind you, I know that many people use cheeky or funny commit messages but normally they include some kind of explanation/context to see what has changed. That's missing here.
This hurts the project. It projects an immature image.
- Follow up to this: How is code quality review done? What are the
procedures to decide when code is added to the repository and how do you make sure that the repository is stable for the majority of the users?
Also I noticed that you do not separate code and HTML output which is another source of potential problems and accidental breakage. Is it planned to rewrite this to use a templating system?
Regards
Sebastian
-- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
* Adam Armstrong adama@memetic.org [2013-06-17 15:36]:
You can get a refund from the front desk.
Okay, that kind of answers my questions I think.
Sebastian
In the spirit of positive feedback, I was also curious about the "always update from SVN" recommendation.
I have two concerns about a constant moving target: Stability and Security
I realize that package updates (RPM,DEB) would operate in a similar fashion to SVN, but I think there are benefits of having more people test a version for a longer period of time.
Any powerful and useful tool (like Observium) has the potential to be the worst disaster for a network. Whether from a malicious attack or unintentional bug, these tools are something that keep me up at night (I use them because I think the benefits are worth the risk).
In summary, any steps to reduce these risks are greatly appreciated.
Thank you Adam for providing us this free software. And thank you Sebastian for your effort to improve this project.
Cheers,
Tristan
On Mon, Jun 17, 2013 at 7:47 AM, Sebastian Wiesinger < observium@ml.karotte.org> wrote:
- Adam Armstrong adama@memetic.org [2013-06-17 15:36]:
You can get a refund from the front desk.
Okay, that kind of answers my questions I think.
Sebastian
-- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Well I doubt observium could be disaster for network as its only reading stuff and not commit anything.
Only disaster could happend and this is when obs stop working and you noticing this late billing for example.
On 17.06.2013 20:53, Tristan Rhodes wrote:
Any powerful and useful tool (like Observium) has the potential to be the worst disaster for a network. Whether from a malicious attack or unintentional bug, these tools are something that keep me up at night (I use them because I think the benefits are worth the risk).
Nikolay,
True, for read-only access the worst failure scenario I can imagine is a loop of some kind causing a denial of service on your devices (high CPU).
I was speaking more generally to tools with write access, including RANCID and NeDi "Device Write" (www.nedi.ch).
Thanks for you input!
Tristan
On Mon, Jun 17, 2013 at 11:04 AM, Nikolay Shopik shopik@inblock.ru wrote:
Well I doubt observium could be disaster for network as its only reading stuff and not commit anything.
Only disaster could happend and this is when obs stop working and you noticing this late billing for example.
On 17.06.2013 20:53, Tristan Rhodes wrote:
Any powerful and useful tool (like Observium) has the potential to be the worst disaster for a network. Whether from a malicious attack or unintentional bug, these tools are something that keep me up at night (I use them because I think the benefits are worth the risk).
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
IIRC rancid support in Obs generally just read only.
On 17.06.2013 21:35, Tristan Rhodes wrote:
True, for read-only access the worst failure scenario I can imagine is a loop of some kind causing a denial of service on your devices (high CPU).
I was speaking more generally to tools with write access, including RANCID and NeDi "Device Write" (www.nedi.ch).
Funny you mention this. Just the other day the hddtemp script brought down one of my Debian machines. Observium's hddtemp script expects nc==nc.traditional which in my case nc==openbsd. nc.openbsd hung at 100% CPU load until the machine self destructed. Good thing we had a backup.
-P On Jun 17, 2013 10:31 AM, "Nikolay Shopik" shopik@inblock.ru wrote:
Well I doubt observium could be disaster for network as its only reading stuff and not commit anything.
Only disaster could happend and this is when obs stop working and you noticing this late billing for example.
On 17.06.2013 20:53, Tristan Rhodes wrote:
Any powerful and useful tool (like Observium) has the potential to be the worst disaster for a network. Whether from a malicious attack or unintentional bug, these tools are something that keep me up at night (I use them because I think the benefits are worth the risk).
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Obviously Adam shouldn't allowed to write unix-agent :-D.
On 17.06.2013 21:41, Paul Strefling wrote:
Funny you mention this. Just the other day the hddtemp script brought down one of my Debian machines. Observium's hddtemp script expects nc==nc.traditional which in my case nc==openbsd. nc.openbsd hung at 100% CPU load until the machine self destructed. Good thing we had a backup.
Early adopters are always going to get burned if there is an issue.
Packages and SVN are just different ways of distributing software. The former doesn't necessarily guarantee that the code will be any more stable than than updating via the latter.
I think the takeaway here is that if you are going to use FOSS and it has the potential to burn you, then a) don't be an early adopter - let others SVN their kit and get issues fixed before updating yourself and/or b) build a lab and vet any changes yourself before rolling it out en masse.
Sent from my iPhone
On 2013-06-17, at 1:41 PM, Paul Strefling strefli3@gmail.com wrote:
Funny you mention this. Just the other day the hddtemp script brought down one of my Debian machines. Observium's hddtemp script expects nc==nc.traditional which in my case nc==openbsd. nc.openbsd hung at 100% CPU load until the machine self destructed. Good thing we had a backup.
-P
On Jun 17, 2013 10:31 AM, "Nikolay Shopik" shopik@inblock.ru wrote:
Well I doubt observium could be disaster for network as its only reading stuff and not commit anything.
Only disaster could happend and this is when obs stop working and you noticing this late billing for example.
On 17.06.2013 20:53, Tristan Rhodes wrote:
Any powerful and useful tool (like Observium) has the potential to be the worst disaster for a network. Whether from a malicious attack or unintentional bug, these tools are something that keep me up at night (I use them because I think the benefits are worth the risk).
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Just a idea: instead of everyone syncing to trunk , a branch or tag could be used.
On commit messages, it is really hurts when you try to figure out when stuff break, wading around "Yarr" and "Puff" under stress is probably not that fun :-D
On Mon, Jun 17, 2013 at 10:58 AM, Jason Lixfeld jason@lixfeld.ca wrote:
Early adopters are always going to get burned if there is an issue.
Packages and SVN are just different ways of distributing software. The former doesn't necessarily guarantee that the code will be any more stable than than updating via the latter.
I think the takeaway here is that if you are going to use FOSS and it has the potential to burn you, then a) don't be an early adopter - let others SVN their kit and get issues fixed before updating yourself and/or b) build a lab and vet any changes yourself before rolling it out en masse.
Sent from my iPhone
On 2013-06-17, at 1:41 PM, Paul Strefling strefli3@gmail.com wrote:
Funny you mention this. Just the other day the hddtemp script brought down one of my Debian machines. Observium's hddtemp script expects nc==nc.traditional which in my case nc==openbsd. nc.openbsd hung at 100% CPU load until the machine self destructed. Good thing we had a backup.
-P On Jun 17, 2013 10:31 AM, "Nikolay Shopik" shopik@inblock.ru wrote:
Well I doubt observium could be disaster for network as its only reading stuff and not commit anything.
Only disaster could happend and this is when obs stop working and you noticing this late billing for example.
On 17.06.2013 20:53, Tristan Rhodes wrote:
Any powerful and useful tool (like Observium) has the potential to be
the
worst disaster for a network. Whether from a malicious attack or unintentional bug, these tools are something that keep me up at night (I use them because I think the benefits are worth the risk).
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
No.
Because then we get hordes of idiots reporting bugs that were fixed long, long ago.
We actually still get people reporting bugs fixed 500 revisions ago, even with SVN. Back when we did .tgz distribution no one ever updated, and everyone reported bugs for versions which were horrifically old.
adam.
On 2013-06-17 19:13, 叶雨飞 wrote:
Just a idea: instead of everyone syncing to trunk , a branch or tag could be used.
On commit messages, it is really hurts when you try to figure out when stuff break, wading around "Yarr" and "Puff" under stress is probably not that fun :-D
On Mon, Jun 17, 2013 at 10:58 AM, Jason Lixfeld jason@lixfeld.ca wrote:
Early adopters are always going to get burned if there is an issue.
Packages and SVN are just different ways of distributing software. The former doesn't necessarily guarantee that the code will be any more stable than than updating via the latter.
I think the takeaway here is that if you are going to use FOSS and it has the potential to burn you, then a) don't be an early adopter - let others SVN their kit and get issues fixed before updating yourself and/or b) build a lab and vet any changes yourself before rolling it out en masse.
Sent from my iPhone
On 2013-06-17, at 1:41 PM, Paul Strefling strefli3@gmail.com wrote:
Funny you mention this. Just the other day the hddtemp script brought down one of my Debian machines. Observium's hddtemp script expects nc==nc.traditional which in my case nc==openbsd. nc.openbsd hung at 100% CPU load until the machine self destructed. Good thing we had a backup.
-P On Jun 17, 2013 10:31 AM, "Nikolay Shopik" shopik@inblock.ru wrote: Well I doubt observium could be disaster for network as its only reading stuff and not commit anything.
Only disaster could happend and this is when obs stop working and you noticing this late billing for example.
On 17.06.2013 20:53, Tristan Rhodes wrote: Any powerful and useful tool (like Observium) has the potential to be the worst disaster for a network. Whether from a malicious attack or unintentional bug, these tools are something that keep me up at night (I use them because I think the benefits are worth the risk). _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
Links:
[1] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Adam don't know how to use branch or tag or/and not willing to fix bugs on both branches ;)
Well its easy when there message in commit like "yarr" just same its just finishing work from previous commit but previous commit contains some lazy errors (testing for rich guys only :-D)
On 17.06.2013 22:13, 叶雨飞 wrote:
Just a idea: instead of everyone syncing to trunk , a branch or tag could be used.
On commit messages, it is really hurts when you try to figure out when stuff break, wading around "Yarr" and "Puff" under stress is probably not that fun :-D
I think people are assuming that there are fewer bugs because a package is created at some arbitrary point in time and not updated for several months.
This is quite clearly a false assumption. It just means you're stuck with the bugs you have for several months.
We distribute via SVN precisely because it allows us to provide bug fixes more quickly.
adam.
On 2013-06-17 18:58, Jason Lixfeld wrote:
Early adopters are always going to get burned if there is an issue.
Packages and SVN are just different ways of distributing software. The former doesn't necessarily guarantee that the code will be any more stable than than updating via the latter.
I think the takeaway here is that if you are going to use FOSS and it has the potential to burn you, then a) don't be an early adopter - let others SVN their kit and get issues fixed before updating yourself and/or b) build a lab and vet any changes yourself before rolling it out en masse.
Sent from my iPhone
On 2013-06-17, at 1:41 PM, Paul Strefling strefli3@gmail.com wrote:
Funny you mention this. Just the other day the hddtemp script brought down one of my Debian machines. Observium's hddtemp script expects nc==nc.traditional which in my case nc==openbsd. nc.openbsd hung at 100% CPU load until the machine self destructed. Good thing we had a backup.
-P On Jun 17, 2013 10:31 AM, "Nikolay Shopik" shopik@inblock.ru wrote:
Well I doubt observium could be disaster for network as its only reading stuff and not commit anything.
Only disaster could happend and this is when obs stop working and you noticing this late billing for example.
On 17.06.2013 20:53, Tristan Rhodes wrote: Any powerful and useful tool (like Observium) has the potential to be the worst disaster for a network. Whether from a malicious attack or unintentional bug, these tools are something that keep me up at night (I use them because I think the benefits are worth the risk). _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
Links:
[1] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
I hope you filed a bug with OpenBSD for being retarded.
adam.
On 2013-06-17 18:41, Paul Strefling wrote:
Funny you mention this. Just the other day the hddtemp script brought down one of my Debian machines. Observium's hddtemp script expects nc==nc.traditional which in my case nc==openbsd. nc.openbsd hung at 100% CPU load until the machine self destructed. Good thing we had a backup.
-P On Jun 17, 2013 10:31 AM, "Nikolay Shopik" shopik@inblock.ru wrote:
Well I doubt observium could be disaster for network as its only reading stuff and not commit anything.
Only disaster could happend and this is when obs stop working and you noticing this late billing for example.
On 17.06.2013 20:53, Tristan Rhodes wrote: Any powerful and useful tool (like Observium) has the potential to be the worst disaster for a network. Whether from a malicious attack or unintentional bug, these tools are something that keep me up at night (I use them because I think the benefits are worth the risk). _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
Links:
[1] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Well, I can't seem to recreate the problem outside of the unix-agent. I need to investigate some more time into the root cause. On Jun 17, 2013 12:01 PM, "Adam Armstrong" adama@memetic.org wrote:
I hope you filed a bug with OpenBSD for being retarded.
adam.
On 2013-06-17 18:41, Paul Strefling wrote:
Funny you mention this. Just the other day the hddtemp script brought down one of my Debian machines. Observium's hddtemp script expects nc==nc.traditional which in my case nc==openbsd. nc.openbsd hung at 100% CPU load until the machine self destructed. Good thing we had a backup.
-P On Jun 17, 2013 10:31 AM, "Nikolay Shopik" shopik@inblock.ru wrote:
Well I doubt observium could be disaster for network as its only reading stuff and not commit anything.
Only disaster could happend and this is when obs stop working and you noticing this late billing for example.
On 17.06.2013 20:53, Tristan Rhodes wrote: Any powerful and useful tool (like Observium) has the potential to be the worst disaster for a network. Whether from a malicious attack or unintentional bug, these tools are something that keep me up at night (I use them because I think the benefits are worth the risk). ______________________________**_________________ observium mailing list observium@observium.org http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium[1]
Links:
[1] http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
______________________________**_________________ observium mailing list observium@observium.org http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
______________________________**_________________ observium mailing list observium@observium.org http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Well, all the agent script does is run
`which nc` localhost 7634
If that's enough to crash your server, I suggest you get better servers.
adam.
On 2013-06-17 20:05, Paul Strefling wrote:
Well, I can't seem to recreate the problem outside of the unix-agent. I need to investigate some more time into the root cause. On Jun 17, 2013 12:01 PM, "Adam Armstrong" adama@memetic.org wrote:
I hope you filed a bug with OpenBSD for being retarded.
adam.
On 2013-06-17 18:41, Paul Strefling wrote:
Funny you mention this. Just the other day the hddtemp script brought down one of my Debian machines. Observium's hddtemp script expects nc==nc.traditional which in my case nc==openbsd. nc.openbsd hung at 100% CPU load until the machine self destructed. Good thing we had a backup.
-P On Jun 17, 2013 10:31 AM, "Nikolay Shopik" shopik@inblock.ru wrote:
Well I doubt observium could be disaster for network as its only reading stuff and not commit anything.
Only disaster could happend and this is when obs stop working and you noticing this late billing for example.
On 17.06.2013 20:53, Tristan Rhodes wrote: Any powerful and useful tool (like Observium) has the potential to be the worst disaster for a network. Whether from a malicious attack or unintentional bug, these tools are something that keep me up at night (I use them because I think the benefits are worth the risk). _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1] [1]
Links:
[1] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1] _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
Links:
[1] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
As I originally stated, that command alone does not produce the problem. But when called from the unix-agent nc hangs at 100% CPU load. And when that happens every 5 minutes it does not take long for the server load to surpass 1000 and bring the box down; this particular case happened in just two days(over the weekend, unmonitored) On Jun 17, 2013 12:46 PM, "Adam Armstrong" adama@memetic.org wrote:
Well, all the agent script does is run
`which nc` localhost 7634
If that's enough to crash your server, I suggest you get better servers.
adam.
On 2013-06-17 20:05, Paul Strefling wrote:
Well, I can't seem to recreate the problem outside of the unix-agent. I need to investigate some more time into the root cause. On Jun 17, 2013 12:01 PM, "Adam Armstrong" adama@memetic.org wrote:
I hope you filed a bug with OpenBSD for being retarded.
adam.
On 2013-06-17 18:41, Paul Strefling wrote:
Funny you mention this. Just the other day the hddtemp script brought down one of my Debian machines. Observium's hddtemp script expects nc==nc.traditional which in my case nc==openbsd. nc.openbsd hung at 100% CPU load until the machine self destructed. Good thing we had a backup.
-P On Jun 17, 2013 10:31 AM, "Nikolay Shopik" shopik@inblock.ru wrote:
Well I doubt observium could be disaster for network as its only reading stuff and not commit anything.
Only disaster could happend and this is when obs stop working and you noticing this late billing for example.
On 17.06.2013 20:53, Tristan Rhodes wrote: Any powerful and useful tool (like Observium) has the potential to be the worst disaster for a network. Whether from a malicious attack or unintentional bug, these tools are something that keep me up at night (I use them because I think the benefits are worth the risk). ______________________________**_________________ observium mailing list observium@observium.org http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium[1] [1]
Links:
[1] http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium[1]
______________________________**_________________ observium mailing list observium@observium.org http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium[1] ______________________________**_________________ observium mailing list observium@observium.org http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium[1]
Links:
[1] http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
______________________________**_________________ observium mailing list observium@observium.org http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
______________________________**_________________ observium mailing list observium@observium.org http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On Mon, Jun 17, 2013 at 10:04 AM, Nikolay Shopik shopik@inblock.ru wrote:
Well I doubt observium could be disaster for network as its only reading stuff and not commit anything.
Only disaster could happend and this is when obs stop working and you noticing this late billing for example.
I think the biggest risk would be if the code was trojan'd and you had IPMI passwords in there, since they're basically the keys to the castle. Granted, you should probably only be giving observium access to read-only IPMI profiles, but BMCs don't always make that easy or straightforward to set up.
On 17.06.2013, at 15:34, Adam Armstrong wrote:
You can get a refund from the front desk.
+1
Daniel Preussker
[ Security Consultant, Network & Protocol Security and Cryptography [ LPI & Novell Certified Linux Engineer and Researcher [ +49 178 600 96 30 [ Daniel@Preussker.Net [ http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x87E736968E490AA1
I understand the sentiment behind this response; but I do feel, if you're asking people to update via SVN, it's only fair to give them some clue what they're getting when they do. So you might want to get past the initial knee-jerk "how dare you criticize something that's free" reaction and at least give this some thought.
On Mon, Jun 17, 2013 at 6:34 AM, Adam Armstrong adama@memetic.org wrote:
You can get a refund from the front desk.
Adam.
Sebastian Wiesinger observium@ml.karotte.org wrote:
Hello,
I'm testing out Observium and I like a lot of the things that Observium does. But what really irks me is the way and style of releasing new versions and committing to the SVN repository.
- Commit messages. To quickly get a feel what changed between
revisions I consult the svn log. That is the primary source of information. In the Observium SVN this often leads me to read things like this:
r4147 - CODE, Y U NO LOOK RITE r4140 - Me need your soul, more souls. >:-> r4139 - you're not ready for this. :) r4125 - disable whatever the fuck that is r4101 - add some crappy errors
And on and on.
participants (9)
-
Adam Armstrong -
Daniel Preussker -
David Brodbeck -
Jason Lixfeld -
Nikolay Shopik -
Paul Strefling -
Sebastian Wiesinger -
Tristan Rhodes -
叶雨飞