New Ktux release. Code is now somewhat more organized and committed into a Subversion repository. Preparing to replace paging code with cleaner and more versatile implementation – this will allow for user-level (x86 ring 3) support. I’ve also started to twit now about Ktux, Linux, and all things science. Follow me here if you like!
Mar
10
I wanted to write a brief posting on some basic ways to help remotely administer Ubuntu/Debian boxes. Over the past few months I’ve been tinkering with various methods of handling this and what I’ve come up with seems to work fairly well. It basically consists of two applications: apticron, which monitors repositories for package updates, and logcheck, which monitors logs in for any security or other noteworthy entries.
Apticron is very easy to set up, it’s in the repositories and requires basically no configuration. It will drop a script in /etc/cron.daily and that is about it, emailing any reports to root. Of course this can be modified through a .forward or an entry in /etc/aliases.
Logcheck is fairly simple to set up as well – it is also in the repositories. Once installed, edit the /etc/logcheck/logcheck.conf file to configure. The first thing you will want to set is the REPORTLEVEL setting, options are “workstation”, “server” (default value), or “paranoid”. I use server on mine, which gives a good amount of detail. I would advise against using paranoid unless the server is extremely locked down and users do not typically login. Workstation is good for a desktop environment. The only other variable I edited was SENDMAILTO. Logcheck works by basically comparing each logentry against a set of regular expressions and generate a report if it does not match. I had to modify one or two regex’s slightly to fix false positives, if you want my changes just ask and I’ll send them over.
One other small gem I want to mention : gkrellm. I use this on both my desktop and server, it is invaluable for providing real-time system performance metrics. Sure, it does not have any logging capabilities and thus unsuitable in a large-scale environment but for keeping an eye on one or two boxes it fits the bill quite nicely.
Mar
5
So it’s been some time since I posted, unfortunately life has kept me on the go these past several weeks and I’ve had limited time at my desk. However, thankfully I was able to work on Ktux from my netbook and now I successfully have multitasking working! I attempted several previous implementations of a scheduler without success, this time I re-wrote mostly everything from scratch, minus a few lines of the timer ISR assembly code. Currently, the scheduler supports thread creation/destruction and basic priority adjustment with nice() (just adjusts the process quantum timeslice). Oh, and a simple yield() was implemented as well. As of the moment, I have a pointer array to keep track of the threads, but in the process of replacing with linked lists (same implementation Linux kernel uses).
The screenshot below demonstrates 4 threads of execution, 3 of them increment counters (with various priorities) and the final one just displays the values on the screen, then yields():
Now, of course with with multitasking support comes a whole new array of synchronization issues. I have intentionally followed the KISS principle thus far when developing the kernel framework, knowing that any substantial code would most likely need to be re-written with critical sections, locks, etc. Due to the complexities and time involved, I am fairly certain I will not aim for full SMP support in Ktux. A few basic atomic operations have been written, but for the moment I think I will just use something similar to the big kernel lock in Linux; performance is not my main concern here, getting something out the door that actually runs is.
Not sure where I will go from here, I know the virtual memory needs a *LOT* of work, it’s pretty ugly right now. From there, I think user-level thread support will be a logical next step.