Touchscreen Solaris NAS

R

rthorntn

n00b
Joined
Mar 27, 2011
Messages
37
Hi

Apologies in advance if this is OT, if so, could you point me in the
right direction.

I am building a ZFS server and looking for advice on how to implement
a touchscreen in the front of it's case.

The screen would show system info, pools and utilization (CPU / Disk /
RAM / Network) info.

Basically when you click on a pool you get a physical disk layout on
the screen with drop-downs for:

-number of disks
-rows
-disks per row
-select slice number beside each disk

And then you save the above info, your layout appears automatically for you.

Disks would change colour based on their status, that kind of thing.

You touch a disk and it brings up a detail page.

Maybe web-based with an auto-refresh capability.

Is software like this available already for Solaris (I have seen
napp-it), if not, any suggestions on the best way to approach this?

Aside from the above software development, How should I approach the
touchscreen function:

1/ Touchscreen plugged directly into the Solaris server via USB and VGA
2/ Something like a beagleboard with touchscreen linked via serial or IP
3/ An iPad or Android tablet linked via wifi

(1) would require a Solaris HID driver for the touchscreen.

Basically it would be cool to be able to:

-touch the screen
-see there was a problem
-identify the physical position of the problem disk
-take it offline...

I would love your input on both the touchscreen and the software dev.

Thanks for your time.

--Richard
 
I was considering starting development on a similar project, just minus the touchscreen, using a standard LCD. I like the ideas you've brought to the table though. I can't say I've ever seen anything like this on the market. I might have to start drawing up some schematics ;)
 
Jesse B: I think you should do it ;)

The screen layout could be:

CPU util
Mem Util
Pools Util
Network Util

Each of those areas could be clicked on, for example: click on CPU it would historically graph each core

You could allow common operations to be performed like shutdown (maybe resilvering or scrubbing)

Seriously I am happy to donate a couple of Benjamin Franklins, it would be the icing on the cake for the case Spotswood is building me.

FYI on the case see the OCAU modding section thread "Project: Storage and Gaming Case" if your interested, in a nutshell a 20" cube with two EATX motherboards, two PSUs and 24 disks. Both computers are water-cooled (2 x Swiftech MCR320-DRIVE). A Solaris install on one PC, Win7 on the other (for gaming).

The Solaris box will have the best hardware: Supermicro X8DTE-F, dual E5606 CPUs, 24GB ECC RAM, SMC10GPCIe-XFP NIC and 3 x LSI 9211-8I SATA cards

--Richard
 
Last edited:
I'll need to do a bit of research and start sourcing some stuff... Need to find an economical way to do this. I'll report back soon.
 
Cool, thanks for that link. That source code could potentially prove to be valuable.

I've done a bit of research, but not a whole lot. Fortunately I couldn't sleep last night, so I was up late reading ;) The hardware aspect of this shouldn't be too difficult. I got a good chunk of it started last night. The software is going to be a monumental undertaking however. I'll keep working on designing the hardware, and once that's done I can decide whether or not to continue.
 
I've basically done all I can schematic wise until I find a source for touch screens. I'm planning on interfacing the MCU/Touch screen via an internal USB header, as that seems like it'd be the easiest way to go about doing things. Anything else I should add hardware wise other than the USB interface (and obviously the LCD interface)? I can't think of a reason to have anything more, but I could be missing something ;)
 
picker: JPerfmeter looks very cool, thanks for that, does it have an optimal resolution?

Jesse B:

Internal USB header is a great idea.

Do you have any particular screens or indeed resolutions in mind?

I found this touchscreen driver for the 3M controller:

http://hub.opensolaris.org/bin/view/Community+Group+device_drivers/touchscreen

As I mentioned before I am more than happy to donate to the development.

Keep up the good work.

--Richard
 
I don't have any particular screen/res/size in mind. I was looking at a standard 4.3" LCD, but that'd need a bracket made in order to fit in two 5.25" drive bays. I'm not sure what would be preferable.

Right now the main thing I'm working on is sourcing an LCD with connector. I've pretty much finished up the schematic until I find an LCD, and have sourced all the parts i need. It shouldn't even be too expensive to produce!

I appreciate your offer for donations, but at this point in time I'm fine with funding this myself. As long as I can find an affordable LCD, this project should be fairly cheap. The most expensive part will be the time it will take to do all the programming. I will most likely need some help when it comes to that, but that's a ways off still ;) Still have a bit of research to do on a few things.

If anyone knows a source of touch screen LCD's, please lemme know!
 
For me it might be a better plan to use the VGA port for video, USB for the touchscreen and 12v power that I should be able to hook up directly to the ATX PSU.

A USB display for video like the http://www.lilliput.cn/UM-1010.html would probably be problematic on Solaris. With the smaller screens is using something like LCDPROC possible?

I am thinking a bigger screen as I have 20" cubed to play with, 8-12" probably.

If the USB touchscreen acts like a mouse then it could avoid some compatibility issues. Not sure if there is a method to calibrate on Solaris.

Gutting this bad boy is the front runner for me: http://www.lilliput.cn/FA1011-NP.html

--Richard
 
Last edited:
Thanks for the info. I may have found some screens, so that's not too much of an issue anymore; I'll still check out what you linked some more though. I was looking at some 4.3" (as well as other sizes) that were quite affordable. I'm still trying to work on getting a complete plan together, so you'll be the first to know when I have.

I'm starting to think that we've got different ideas going on here (not saying that's bad at all). The design I'm currently working on would have all the video/touch screen managed by an onboard MCU, which would allow you to simply have a program running on your still headless server, and just send serial information to be processed over the USB link. This would allow you to still have your server headless, while having a GUI on the LCD. This would be mounted in a pair of 5.25" bays.

If you were wanting more of a full-sized monitor solution, that could still be done using VGA run off the MCU, or you could use the onboard VGA on your server. If you wouldn't mind just explaining exactly what you were expecting, we can definitely go from there. :)

The beagle board solution is nice, but there was just a LOT of features that aren't necessary for this application, so I was just designing my own mainboard with the minimal amount of parts.
 
IMO most pragrmatic solution would be to setup a browser based interface (ala napp-it, etc). You would use the same techniques (shelling out to standard zfs, etc. commands & parsing the output). For your needs the interface would just have to be "fancier" - most of the current gen browsers should support touch events just fine, and there's HTML for working with them.

In your example the "program running on the headless server" would just be a webserver, and instead of a USB link you would be wired/wireless. You could even use an iPad as your status display.

Barrier for entry for getting stuff up and running in HTML is probably lower than some other programming language - there's certainly plenty of resources/examples available on the web - and you can look at the napp-it source for examples of getting/sending system level commands to get/receive data. An HTML interface also makes a more flexible (and more applicable to most people) interface than a hardware attached MCU, so your chances of getting other people to contribute would be higher.
 
Jesse B, I was confused thanks for clarifying, I didn't pickup on the abbreviation MCU.

Your idea does sound best (although more work) as it would be preferable to have a single cable and to not have to worry about touchscreen drivers in Solaris.

Agreed Beagleboard is overkill.

So MCU to Solaris is USB, what would you use as the interface between MCU and touchscreen as I would prefer something a bit larger?

Check this out:

The LCD:
http://www.gumstix.com/store/catalog/product_info.php?products_id=244

The Overo:
http://www.gumstix.com/store/catalog/product_info.php?products_id=211
http://www.gumstix.com/store/catalog/product_info.php?products_id=229

Or the older (less powerful but cheaper) Verdex...

--Richard
 
ChrisBenn: makes sense as you have many more options.

You could have:

Display connected directly to Solaris displaying web page. (most cable clutter)
MCU connected via wifi or ethernet displaying web page. (cheap option)
Tablet connected via wifi displaying web page. (easiest option)
Any device with a web browser anywhere in the world displaying the web page.

Jesse B: any disadvantages?

Web server on Solaris with MCU (running linux?) connected with ethernet displaying web page sounds best. You could have both a web server (HTML5?) and maybe a java app (ala JPerfmeter)?

Wifi maybe unreliable when mounted inside an aluminium case (you could punch a hole and have an external antenna).

Should we look at the web server option, the Beagleboard MCU have more than enough grunt to display a web page on either a small LCD or HDMI to a larger screen?

--Richard
 
Not trying to hijack this thread, or dampin enthusiasm, but a headless solaris box with apache <--> ipad interface is a cool easy idea, but I'm not sure it would cover enough problems to be "useful".

perhaps a slight change of focus to no touch keyboard and mouse and work on a program that ran at boot and on the VGA displayed system status. fan speeds, cpu and io loads, and flashed red when a condition was out of spec. Leave the resolution of that issue to someone to ssh in or whatever.

That said, I autostart jperfmeter with an old FingerWorks mini keyboard/mouse combo (HID usb) on mine. but one could also save rpc.rstatd data in rrdtool and start a local browser and auto REFRESH the page so the data is available local on VGA and remote via apache.
 
Beagleboard-XM $149

It can be USB powered
It can drive a monitor
It has ethernet

This driving the:

Lilliput FA1011-NP/C/T $229

I may need to add a USB powered hub to this.

Could be optimal for me.

--Richard
 
Last edited:
Picker: thanks for the input.

Personally I think the touchscreen is the most important element, nice and clean as well as functional.

--Richard
 
The thing that just hit me is the case I am having built has 2 PCs inside, one for ZFS and the other for Win7 gaming, it would be cool for the webserver to run on the beagleboard so I can monitor both PCs from the same screen...

UPDATE: FYI the actual URL of the case project so you can see what I am rambling on about: http://forums.overclockers.com.au/showthread.php?t=952781

--Richard
 
Last edited:
Come to think of it, I have a ASUS Eee PC T91 MT I rarely use...

Windows 7 Home Premium
Intel® Atom Z520
1GB RAM
WLAN 802.11b/g/n
Bluetooth 2.1 + EDR
32GB SSD
D-sub 15-pin VGA Connector
2 x USB 2.0
1 x LAN RJ-45
MMC/SD (SDHC)
Li-polymer Battery, 5 hrs

I could tear it to pieces leaving the display and mainboard and mount the two parts in the case...or I could not bother dissecting it at all and put it in whole (use some 3M heavy-duty double-sided tape -- it's 28.4mm high and I have 50mm of clearance in the case)

I will probably try wifi but end up using ethernet.

Putting Linux on there shouldn't be a problem if required.

So if I use the T91 extending napp-it to be more graphical is probably the way to go?

Some JPerfmeter goodness in napp-it would be lovely.

--Richard
 
Last edited:
Lots of activity in this thread since I checked last :D

ChrisBenn: I think your suggestion is a fantastic one. This would make much more sense, rather than writing a background process, just utilize and already-running web server. Not only does it make the programming much easier, but it allows for much more flexibility as you said. You could have the touch screen mounted in your server (if you so wished), as well as possibly have an Android/iPhone/iPad app, or just use your main PC's browser. This indeed offers much more flexibility.

rthorntn: I'm still researching what the best method of connecting the LCD to the MCU would be. I haven't looked into it too too much, as I've been researching other things. It would either involve an additional video-control IC, or simply interfacing with the existing MCU. I'll hopefully be able to tackle this issue tomorrow. Just wasn't enough time in the day today to get everything I would have liked done :) VGA would also be an option. The thing about designing your own mainboard and PCB is that you can have whatever you want! :D

Wi-fi or Ethernet are also an option. Again, developing the system yourself gives you muchos flexibility.

The BeagleBoard should have more than enough oomph to display a simple web page.

Picker: You have a valid point, and that's definitely worth considering. I have a lot of figuring out to do before I hunker down and place an order.

rthorntn (again): Very cool case build! :D

Anyways, tomorrow I'll sit down with a pen and paper and start doing some real figuring. I think that I'll try to get a few solid, well-planned ideas, and then come back and ask for opinions as to which would be optimal. It's very likely that I could end up following through with more than one option.

Anyways, this can all be taken care of in the morning. I'm exhausted.

Thanks a lot for the input so far everybody, I'll do my best to make some progress tomorrow.


- Jesse
 
I lied, I'm back. I wrote what I wanted to accomplish with this project (by compiling suggestions from the thread), and planned two options.

This project should accomplish the following:

Show system info, pools and utilization (CPU / Disk / RAM / Network) info.

When you click on a pool you get a physical disk layout on the screen with drop-downs for:
-number of disks
-rows
-disks per row
-select slice number beside each disk

And then you save the above info, your layout appears automatically for you.


Disks would change colour based on their status, that kind of thing.
- You touch a disk and it brings up a detail page.
- Maybe web-based with an auto-refresh capability.

Have a clean, simple interface. Have tabs or panels for different things. Have one for basic system monitoring, such as CPU/Memory utilization, temperatures, fan speeds, etc. Have a second tab to monitor disk and pool information. This would allow for expansion of features and give a very clean interface, imo.
Click to expand...

This is what I think should happen. If anybody feels I've left anything out, or don't quite have a concept correct, please step in and let me know!

As far as utilizing this project, I feel there are two major options.

OPTION 1:

Utilize existing web-server
- Write script to run ZFS commands, parse the output
- Send parsed output to dynamic web page/interface
HARDWARE:
- Touch screen connected to ethernet/wi-fi -capable device

OPTION 2:

MCU mainboard connected to host via USB
- Touch screen connected to/controlled by MCU
- Background process monitoring various things
- Send information to COM port
- MCU processes and displays said information
Click to expand...

I honestly feel that option 1 would be best at this point in time, just due to its simplicity and flexibility. Again, please chime in if you have any suggestions or comments.

That's it for tonight. My brain is toast.


- Jesse
 
Jesse B: That is perfect!

Basically people can solve the "browser" requirement anyway they want.

Option 1 maximises the time spent on a useful interface.

The SourceForge page has the features on there and I am continually updating this.

Would you consider creating a SourceForge account so I can add you to the project?

Good night!
 
Last edited:
or how about you use napp-it from your iPhone? hahaha ok but seriously this is actually a good idea. this would be so awesome to show off to my friends.. who are already intrigued by my NAS as it is....
 
rthorntn said:
Jesse B: That is perfect!

Basically people can solve the "browser" requirement anyway they want.

Option 1 maximises the time spent on a useful interface.

The SourceForge page has the features on there and I am continually updating this.

Would you consider creating a SourceForge account so I can add you to the project?

Good night!
Click to expand...

Thanks! I've created a SourceForge account, it's just jessebraham (everything seemed to be taken, oh well).

dmo580 said:
or how about you use napp-it from your iPhone? hahaha ok but seriously this is actually a good idea. this would be so awesome to show off to my friends.. who are already intrigued by my NAS as it is....
Click to expand...

How I'm envisioning things is for this to be an additional interface that could be used in conjunction with other interfaces. Napp-it is more for system management, while this interface would be more for monitoring and troubleshooting purposes. I'm sure they can coexist. :)

I'm going to start doing a bit of research and planning today. Hopefully I'll even be able to start writing some code if everything goes well!


- Jesse
 
Also regarding the "browser" requirements as you put, there are numerous options with this method:

1) Web interface, usable from anything on the local network
2) App for Android/iPhone/iPad (wouldn't be difficult to develop)
3) Custom hardware such as a setup we were initially discussing

I know I'd like to be able to monitor things off my Galaxy S, so Android app will probably be step 1 after the core interface is complete ;)
 
Alright, well so far today I haven't gotten quite as much done as I would have liked. I did get a fair bit of boring, mundane stuff done however.

I've got a good chunk of the initial planning done. This can be seen in the below linked file. I think I've covered most of everything, but if there's anything vital you guys feel I've left out, or even just your feelings, please let me know.

Coding wise, didn't get a whole lot done. Wrote a TINY bit of HTML, and wrote a bunch of pseudo-code for various functions that will be vital to the operation of this package. Me and the woman's anniversary tonight, so not sure how much time I'll have tonight to work. Hopefully try to get a bit more in ;)

Thanks,


- Jesse

FILE: http://db.tt/uvcL5oo

(Sorry, uploading it screwed up the formatting at the top a bit. Don't care enough to fix it)
 
I've updated the *.txt file to conform with the features listed on the SourceForge page. I'm not too sure about a few of the features, as they are a bit outside my idea of the scope of this project, but they can be discussed and decided upon at a later date.

I've got quite a bit to do around the house today (new kitchen!), but I'm hoping to get a bit of work done. I've started coding a few functions to interface smartmontools with the web page. Just have to work on parsing the output and they're good to go. Hoping to at least get those completed tonight.

I'll post another update later tonight if I've made any progress.

Thanks,


- Jesse
 
I've started making a bit of progress here. I've pretty much written all the code I need to interface with smartmontools via php. Had a few issues to due with permissions to work out, but it ended up being a pretty simple fix.

I think once I get a bit more code done, I'm going to start a new thread dedicated to the project. I'll keep everyone updated.

Thanks,


- Jesse
 
I tossed in 100 for additional funding as I would definitely use this - looking forward to seeing where this goes!
 
Hey Jesse,

Great news on the progress, nice work.

Any idea when you may have some code that is ready for testing?

Thanks!

--Richard
 
Unfortunately I just started a new job as of last week, and have been EXTREMELY busy. I've put in about 100 hours in the last two weeks. So unfortunately, I haven't had a whole lot of time to work on this project.

I have got a fair bit of work done however. I have the basic layout for how the pages are going to look (for now that is, prone to change). It's just basic, because I'd like to get a usable interface before worrying too much about aesthetics.

I've written quite a few functions so far as well. As I mentioned, everything to do with SMART has a function written for it. I've also written some system-related functions such as detecting the amount of disks connected, and finding the total/used/free memory.

I've just started doing a bit more of the exciting stuff. I need to play around with RGraph a bit, and still explore a few more tools. I'm hoping to have system monitoring/graphing within a week or two, but it just depends on work. From there, I'll start worrying about all the disk/pool related business.

My apologies for the rather slow and uneventful development, but as I've mentioned, life has gotten in the way ;) I'm hoping to start working on it a bit more, and I'll be sure to post any exciting updates as they happen.


- Jesse
 
Just got the memory portion working ;) Not necessarily how things are going to look, I just did it this way to display the information I wanted to see.

mem.png
 
ChrisBenn said:
http://blog.harschsystems.com/uncategorized/remote-cpu-monitoring-using-node-kstat/
Just flagging that in case there is anything useful to you there - looks like he has some existing server side monitoring code (that blog post is specifically on adapting some of it to run under a node.js server)
Click to expand...

Awesome, thanks. I'll definitely take a gander ;)

ChrisBenn said:
Also if you are taking requests some ARC/L2ARC and ZIL usage stats would rock :)
Click to expand...

Already on my list of things to do after the core features are finished :)
 
You must log in or register to reply here.
Back
Top