Show HN: Linux server monitoring web dashboard

by afaqurk • 12 years ago

175 68 12 years ago

ivan_ah• 12 years ago

Very cool.

How difficult would it be to create widgets that show application-level stats like number of visitors on site or conversion rates (e.g. calculated from google analytics).

I'm tired of having to loging to google analytics, lulu.com, and gumroad in three different tabs....

batuhanicoz• 12 years ago

Take a look at Dashing[0] by Shopify, it can be a base for what you want. There is already a Google Analytics plugin[1]. For Lulu.com, they are saying they are not accepting new developers[2] but if you have an API key, you may have luck building a widget for Dashing.

[0] http://shopify.github.io/dashing/

[1] https://github.com/Shopify/dashing/wiki/Additional-Widgets

[2] http://developer.lulu.com

skyebook• 12 years ago

Dashing is gorgeous and surprisingly easy to write widgets for.. Hardest part was getting the layouts right.

afaqurk5• 12 years ago

As of now it is a very simple application. I am going to now start planning the roadmap for this as a product. Things like an API, integration with web services, etc. I'd say a few months down the road, your requests will be very viable.

Edmond• 12 years ago

you sure you don't want to make a go at turning this into a full blown product? Imagine a more modern version of webmin. Very nice.

wazoox• 12 years ago

Webmin still works and is actively maintained. There even are good-looking themes nowadays. It would be a huge endeavour to re-implement all that came into webmin in the past ten years.

prottmann• 12 years ago

But Webmin not satisfies the NIH-Syndrom ;-)

afaqurk5• 12 years ago

Exactly my intention: get feedback and then iterate towards a more viable product. I have quite a few more ideas for the interface and options. Definitely going to pursue it.

ronaldsvilcins• 12 years ago

Pretty awesome!

robinhoodexe• 12 years ago

Neat, I'd like this to monitor my Pi... Just because I can.

tjohns• 12 years ago

I was actually just thinking the same thing. This would make a great status page for a headless RaspberryPi.

ababab• 12 years ago

Could you add installation/setup instructions?

amjd2• 12 years ago

There's no installation, just git clone and move to your www directory.

$ git clone https://github.com/afaqurk/linux-dash.git

$ mv linux-dash/ /var/www/

mryan• 12 years ago

That assumes you have a web server configured to serve PHP out of /var/www.

At the very least you would want to put some access control in front of this.

_offset• 12 years ago

Minor typo on the header: Dashboad

Looks really nice. Was this built for Debian-based distros?

afaqurk5• 12 years ago

Thanks for the correction. Yes, this version was built for Debian distros. Working on more comprehensive support for the next iteration, which will have an API.

k0• 12 years ago

Not much different than conky...except the web service part.

http://conky.sourceforge.net/

Sir_Cmpwn2• 12 years ago

Can I use conky to monitor a remote server? I'd like that.

potash2• 12 years ago

Of course! ssh -X. Obviously requires conky (and a minimal X server) on the server.

jdost2• 12 years ago

You could use the conky-cli build (without the X dependency). You could then run it and pipe the output into some file that you serve statically. Hmmm may spend some time investigating.

jdost2• 12 years ago

To follow up with this. You could add `conky -c json.conky | while read json; do echo $json > /opt/http/monitor/info.json; done` to your start. Then just static serve the `info.json` file and it should update at whatever interval you set for conky. No dynamic execution though (hard part is that lack of interaction).

carbocation• 12 years ago

I believe the memory assessment will always show basically no free memory due to Linux's memory management and caching. It would make more sense to subtract out the cache to see what's really used and what's just being (smartly) cached.

afaqurk5• 12 years ago

You are right. I'll have to make that adjustment.

gprasanth• 12 years ago

Just linking for anyone wondering. http://www.linuxatemyram.com

riquito2• 12 years ago

Nice interface, but it's a bit strange to me that it uses shell exec for every kind of measure.

e.g. # uptime.php <?php echo (int) (shell_exec('cat /proc/uptime')/(60*60));

afaqurk5• 12 years ago

Yea, that's my #1 concern now that I know its worth pursuing as a more well developed product. I'm hope to step away from PHP totally for the next iteration. This was more-so a proof-of-concept for the sake of feedback.

riquito2• 12 years ago

I was thinking about not forking processes to read a file, not to avoid the use of php, if you're comfortable with that.

What ideas do you have about reading the stats? You'll have to use a server side language anyway (or do you plan to read data from a third party service with a restful api?)

edit: if you want to have a zero-install tool I'd suggest to go with python plus bottle (a one file webframework), so that you would be able to clone and use it from any directory.

atmosx• 12 years ago

Yes, seems incredibly insecure approach, although the interface is beautiful.

zaroth• 12 years ago

Be careful of any externally controllable strings which might allow XSS and give panel access to an attacker.

More of a problem for admin dashboards which have two-way control, which this one must if it can do on-demand refresh.

That's why I prefer munin static pages.

sneak• 12 years ago

Better idea: output the output of ohai and then handle the display in JS.

jdiez1712• 12 years ago

The interface looks very nice but no thanks, I'm not going to install PHP on my servers to have it. I'd totally set it up if it weren't for PHP. The risk is just too great to ignore.

kodablah2• 12 years ago

Some server side code is required to obtain the data. Out of curiosity, what would it have to be written in to make you feel safe?

jdiez1712• 12 years ago

In anything that is not PHP. Bash would have been perfect for this use case, for example. The correct way to do this is to obtain the data separately and merely show it on the interface. I haven't audited the code, so I don't know what's being passed to the shell commands, but the fact that an attacker MIGHT be able to influence the commands being executed (see register_globals, etc (yes, I know this has been disabled by default in recent versions of PHP)) is enough for me to completely write it off as an unnecesary risk.

By collecting the data periodically (i.e a cron job) you eliminate most possible vulnerabilities.

bradleyland• 12 years ago

Server monitoring applications, by their nature, have to interact with the system by issuing the commands that will collect data. The most common solution is to separate the application in to two parts:

Back-end: a daemon process that runs at an interval, collecting data and writing it to a data store.

Front-end: connects to the data store, processes statistics, and formats for display.

By constructing your application in this way, the data store acts as a firewall between the system calls required to collect the data and the interface used to view the data. Your daemon application needn't listen on any network ports if it is running locally.

Your web application still needs to be secure, but you don't have the additional risk of many calls to system/shell exec commands that are a honey pot for exploitation.

rschmitty• 12 years ago

Have you even looked at the (trivial amount) of PHP source code? Where is PHP going to be attacked? Perhaps I am missing something obvious but it seems like PHP is running some linux commands and parsing the results, not sure how this would be different/safer in another language?

Also you can put it behind http auth or restrict the vhost by IP etc

jdiez1712• 12 years ago

It's not how much PHP is running, it's that PHP is running _at all_. It makes me feel very, very uneasy that every time that web interface is hit PHP executes a shell command. There's something inherently wrong about that, to me.

condiment• 12 years ago

I had the same attitude, so I forked it and rewrote the PHP endpoints as a Python script, which I execute outside of the context of the application via a cronjob.

https://github.com/arbuckle/linux-dash

jdiez1712• 12 years ago

Thanks, that's how it should be done. I don't care if the collection script is written in Python, Ruby, Node JS or Brainfuck; it shouldn't execute shell commands when it receives a HTTP request.

itsderek23• 12 years ago

Checkout https://github.com/scoutapp/server_metrics (Ruby - gem install server_metrics). Grabs all the key server + process metrics, handles Linux memory cache, etc.

Requires a distro w/ "proc" functionality for the most metrics.

e12e• 12 years ago

Thanks, this architecture makes more sense imnho. Between this and the other thread on monitoring solutions, I wonder if it would be worth it to write a snippet that takes data from sar [ed:sar/sysstat or perhaps conky] and dumps out json that works with this dash...

damiongrimfield• 12 years ago

"The risk is just too great to ignore."

Can you elaborate on this? I'm looking for you to clarify which other dynamic languages would be considered less risky in this specific application and why.

jdiez1712• 12 years ago

Other dynamic languages have similar risks but at least they don't have a history[1,2] of making completely stupid decisions when it comes to security.

However, I'd rather not have a program execute a shell command when it receives a PHP request. Written in PHP or not. It's just wrong.

[1] http://www.php.net/manual/en/security.globals.php

[2] https://bugs.php.net/bug.php?id=47796

pawelo• 12 years ago

I made similar dashboard app a year ago, written in python with extensible and configurable metrics https://github.com/Eyjafjallajokull/aboco also supports application-specific stats.

jqm• 12 years ago

Very Cool. Would be nice to show Apache access logs as well (careful parsing those:).

martius• 12 years ago

I think you should remove the animation on the numbers: it prevents the user from reading quickly valuable info (and isn't really useful anyway).

Still, the interface is really cool!

vinodhdavid• 12 years ago

True using PHP would also have server dependant issues as well as security issues. I feel PHP is a web framework and would suggest using a application framework for this.

Cyberpew• 12 years ago

This looks very nice!

However, multi-server support would make this even more amazing.

Show HN: Linux server monitoring web dashboard

Related Stories