Anyways, as this is shared here on a developer oriented forum, it would be fitting to speak of the actual implementation too. Taking quick look at the source, it seems to have some security issues ranging from XSS to potential CE. These seem to arise from common bad practices.
I would advice going through the source code and making sure all values you echo as JSON are properly encoded and that you don't use anything as-is in a shell command.
You are absolutely on point. I am currently cleaning up the code base and trying to instill a better directory/file structure. Since the last post, it has added more widgets, changes to existing widgets, and been put up on a new domain. Seeking feedback to help it mature a bit.
I deployed it on apache with a .htaccess limited to my domain to limit security issues. Pretty trivial. Perhaps you could expand your documentation on this note. Just include a few lines on how to stick a file in the root folder with something like this
RewriteEngine on
Order Deny,Allow
Deny from all
Allow from IP or partial IP
Allow from domain
Also make sure the overall apache config has a directory tag with allowoverride all. Debain defaults to allowing none.
The most important widgets for me are general info, load average, ram, disk usage (actually, I would mostly like a widget that highlights when a disk is below 90% free space, so maybe that is a new widget) and processes. I changed it so these are sorted at the top by default, also I changed the sorting when clicking on cpu/memory etc to display the highest values instead of the reverse which is the default. I dont know how much of this is something you would like to implement, and all of it is trivial, but if you want my changes reach out.
I started this fork in part to port it to go and in part to create a set of packages for getting at linux system information(for use in monitoring agents, etc). I haven't visited it in a while but it's always in the back of my mind in case anyone would like to contribute :)
There are actually quite a few github users who have ported the project to Go, Ruby, Python, etc. I believe there already exists a popular java based alternative.
Node would be awesome for a project like this. Especially with Gulp. If someone hasn't already built it, I would love to.
Node would be overkill for a project like this, though. It's a lot to install, manage, compile, etc. just for a simple, relatively static dashboard that just collects basic stats, especially if your package manager doesn't have v8 and node in its repos.
I feel as though the great thing about this project is its drop-in-ness (which is difficult to provide without PHP) and its flexibility; for example, I can put this on a server behind Apache, running PHP, and set up LDAP authentication to restrict access to it. With Node, that's a huge amount more work for little to no gain (since I would probably just put it behind Apache anyway).
Just my two cents, but as much as I find PHP distasteful, it really does feel like the best tool for the niche the tool currently serves.
A simple Python version that could serve out JSON data and a nice frontend that could collect and display it all (in groups) would be a nice way of having essentially a live munin graph. That would be cool.
php is ok for this type of work. Unsexy as it is, I think it's better than Java. For running a simple poller, gathering a metric, with the JVM you get one of two (poor) scenarios: either a slow starting short lived poller process, or a long lived memory hungry long lived process. Neither is acceptable for this use case.
Take a look at Amonone - https://github.com/martinrusev/amonone
It is a lightweight monitoring tool written in Python with charts for all system(cpu,disk,network,etc) and process metrics(cpu/memory). Plus it has alerting with email/sms notifications.
I find it rather crazy that "cockpit", an almost brand new project has its entire backend written in C. Not your typical backend language by any means...
Well it does make deploymeny really simple, since it'll have such light dependencies. If it's statically linked it could even be as simple as unpacking a tar file.
Go is less useful on older systems, since you have to go out and get the Go compiler/etc. and compile them yourself before you can compile anything else, whereas you can expect that all systems (not just recent ones) have a C compiler installed.
Do you have plans to break apart the monitoring and reporting, so that one monitoring node could monitor the statistics of multiple servers? Something like www.scoutapp.com (proprietary) or Cacti (open source). That would be really cool. I'm growing a network of 100's of servers, and not about to pay scoutapp $10 per server... so something equivalently nice looking, but open source, would be awesome.
Absolutely. We recently created a multi-server branch for linux-dash. It just began but the goal is exactly what you stated: single, consolidated Linux-dash page for N servers with the same drop-in installation capability.
What's the progress like? Are you strapped for time? If you need help funding this specific aspect, I would be interested in fixed-rate contract work. Email in profile.
Is there something particular you want to specifically mention that has happened since you last shared the app five months ago? - https://news.ycombinator.com/item?id=7125153
Anyways, as this is shared here on a developer oriented forum, it would be fitting to speak of the actual implementation too. Taking quick look at the source, it seems to have some security issues ranging from XSS to potential CE. These seem to arise from common bad practices.
I would advice going through the source code and making sure all values you echo as JSON are properly encoded and that you don't use anything as-is in a shell command.
Few examples:
- https://github.com/afaqurk/linux-dash/blob/7bd5dcb637f815702... - https://github.com/afaqurk/linux-dash/blob/7bd5dcb637f815702... - https://github.com/afaqurk/linux-dash/blob/7bd5dcb637f815702...