We've pushed out new RC (Release Candidates) builds for part 1 of the upcoming TurnKey Linux 11.0 release and we need your help testing them! See the appliance pages for download links.

The current crop of release candidates only include Ubuntu Lucid based ISO images for now. Debian Lenny based images will follow, as will builds specially optimized for the the full range of supported virtualization and hosting platforms (e.g., VM build, EC2 AMIs, ESX4, Xen, Eucalyptus, etc.).

In part 1 we've updated all the existing appliances except for Zimbra and Openbravo which we haven't got to yet. They'll be in part 2 along with all the fantastic new appliances developed during the community development contest.

We broke up work on the next release into two parts because with all the new appliances the size of the appliance libary is doubling and that was a bit too much to handle in one go.

Also, Alon is flying off to Orlando today for the Ubuntu Developer Summit and we wanted to have something out the door to show off to our friends in the Ubuntu community.

New versioning scheme

Instead of date based versions the new versioning scheme tracks TurnKey Core, regardless of the date or the underlying distribution.

In other words a TurnKey Linux 11.0 appliance based on Ubuntu Lucid and a TurnKey Linux 11.0 appliance based on Debian Lenny are the same version because they have the same Core features.

We're also hoping to get rid of some of the confusion with date based releases. For example, we pushed out the maintenance release 2009.10-2 in April 2010 but the version confused many people into thinking the appliances were obsolete, even though Hardy will be supported for another 3 years and security updates were installed on first boot and daily afterwards.

Now built-in: TKLBAM (TurnKey Linux Backup and Migration)

TKLBAM, which we announced a few weeks back as a separate component, is now tightly integrated with TurnKey out of the box. This includes a spiffy new Webmin module so users who dislike the command line can fully enjoy TKLBAM from the comfort of their web browser. Now you can backup and migrate fully working systems anywhere with literally just a few mouse clicks.

As an old school Unix guy who loves the command line, what I like the most about the new Webmin module is how it facilitates easy discovery of TKLBAM's functionality and ties everything together seamlessly. No need to memorize funny command line flags or decipher manual pages for configuration options. At a glance you can see what can be done. If you don't understand something you just click on the question marks for embedded help pop-ups.

Screenshot #1: backup menu

Screenshot #2: restore menu

New Core features

Besides TKLBAM integration, we've made a broad range of improvements to the Core features shared by all appliances. In fact one could argue more has changed between the last beta and the release candidate than between the previous release and the beta.

Basic configuration dialogs on first boot: Previously only ISO builds would prompt you, during installation, to configure the appliance (e.g., set passwords). Users of the pre-installed builds (e.g,. the virtual machine build for VMWare/VirtualBox) had to do basic configuration by hand.

With the new mechanism, the user experience is consistent for all build types. Also the first boot configuration mechanism is modular so appliance customizers can easily add their own hooks.

LVM (Logical Volume Management) support: instead of installing the appliance filesystem to a naked partition, we setup LVM by default. This makes it much easier to adjust storage capacity later. Also it adds basic support for filesystem snapshots, which future versions of TKLBAM may leverage to support new kinds of databases.

Inverted webshell color scheme: real men use white on black for their command line shells. And they like it!

Display system info in the login motd: seen in the above screenshot.

Appliance specific changes

The latest and greatest: all appliances are now built using the newest software packages available with Long Term Support from Ubuntu. For software not available in the package management system (e.g., redmine), the latest stable software versions from upstream are used instead.

A range of performance optimizations: for example...

All LAMP-based appliances now includes xcache for PHP opcode caching which improves PHP performance, as code only has to be recompiled by PHP into opcode if it changes, and not on every page load.

All Rails based appliances now come with Ruby Enterprise which improves memory performance, traditionally one of Ruby's weak points.

Many small improvements and bug fixes

Exciting potential for new bugs: as yet unidentified.

Distribution level changes

Upgraded base distribution: from Ubuntu 8.04.3 to Ubuntu 10.04.1

The good: newer packages based on a new Ubuntu LTS release which will be supported for 5 years.

The bad: roughly 50MB in additional bloat for all appliances. This is mostly a consequence of bloated dependencies within the new Ubuntu version. Some of the dependencies are unnecessary for our use case (e.g., plymouth) but the only way to get rid of them is to fork the packages and we'd rather avoid that.

Fortunately, the upcoming Debian Lenny based builds do not have this extra bloat so anyone who cares will have an alternative.

No more pinning: As discussed earlier we've discontinued use of complex package management configurations to achieve mixed hybrids of Ubuntu and Lucid.

I particularly like the way that TKLBAM is so tightly integrated that it definately looks like a fundamental part of the appliance (as it indeed now is)!

The new versioning scheme makes lots of sense (although personally I didn't mind the date based system). The config questions running on first boot, makes install and config consistent regardless of the image format which is very nice!

Congratulations on yet another milestone (they seem to come so rapidly - amazing given the human hours available). I'm digging in straight-away with dokuwiki, and I'll see where I'm taken from there. Looking forward to giving any that I can find a use for a go.

Great work,

Rik

---update---

Installed the Lucid RC of Dokuwiki into a VMware VM using Workstation. Wonderful stuff. Love the integration of TKLBAM and how it's worked into both confconsole and, more brilliantly, into Webmin. Love the opportunity to configure TKLBAM on first boot after installation along with the root password. Installing from the ISO to VMware was more painless than installing from repos onto a Lucid server on bare metal, which I have found to be nothing short of a pain in the neck (yeah, could be a problem between my brain and the keyboard - but the point stands that there's no such problems with TKL's appliance).

One thing I've been thinking about is providing easy instructions for changing the default passwords. I know for many of us, it's a few clicks away and possibly a search in Google. For some, however, that may not be the simple process it appears to be from our perspectives. I've thought about this particularly since I'm hosting appliances at our students' site and realize things may be smoother for the end user if we provided more than the default credentials: actual guides to changing and setting passwords so the appliances are more likely to be secure; even if those guides are just links to other documentation, it might secure one more user who may otherwise stay vulnerable. Of course, we haven't done this because of time constraints. Obviously it's more than likely that neither of you have the discretionary time for documenting something like what I'm describing here. Just some thinking I thought maybe I'd share.

I reckon thats a great idea. I imagine that the best place for specific resetting password info and other similar stuff would be on the Appliance Specific Wiki pages.

I think it would be great if all appliances had their own specific appliance wiki page (even if its only a blank placeholder page to start with) with a link from the (dev produced) appliance page. I guess it may be a little frustrating for some if they go to the Wiki and it's blank, but perhaps all the blank ones could include a basic template offering some suggestions of where to start looking for info and perhaps some links to relevant forums, wikis, base info, etc that are relevant to that appliance. Just adding my 2c in the mix :)

I suggested the same thing some time ago, you can see my last comment on this thread. There are some ideas for the webpage including the ones you're proposing here. I hope I'll receive some feedback from the guys, once they come alive again on the forums. And yes, it's a lot of work. But we can do it, it's a matter of stablish a standard "template" so we can contribute but keep consistency on the information.

Interestingly, some of your ideas were actually part of the original design I sketched on paper last time we refreshed the web site. It just didn't make the cut due to time limits.

The website is overdue for another round of improvements. We're in complete agreement on that. How soon we get to it is mostly a matter of priorities (e.g., spend a few weeks refreshing the web site or work on 64-bit builds).

One of the ideas Alon and I have been kicking around is to add support in the confconsole for reinvoking the firstboot configuration scripts. That could provide an easy way to reset the most important passwords. Hopefully we'll manage to work that into the final release!

I think TurnKey's mantra: what can be easy, should be easy. applies here. I'd like to add inithooks that allow the user to set the application passwords on first boot instead of having default passwords. This would alleviate the need for much documentation.

But, there is a catch - we still need to support deployment of appliances where the user does not have direct access to the console on firstboot, such as on Amazon EC2 and other hosted options. We can make the process seemless using the Hub and pre-seeding (but that hasn't been implement as of yet).

So, we would still need default passwords and have them documented some where. But this is still a step forward.

We could also add an option to the confconsole as Liraz mentioned allowing the user to reset passwords, but that means the inithooks need to be aware (or at least take into consideration) the state of when they are being run - as services might need to be stopped and/or restarted.

1. Warnings during instalation. The text based installation keeps giving some warnings which make the text go outside bounds and looks ugly. Everything works fine, but it could fright a new user.

2. Boot from harddisk? I miss this option but I can live without it. It just that when I'm developing patches, I reuse my VMs attaching the iso and alternate between booting live/from hard disk. Also, as the installation doesn't eject the CD at the end, a newbie would get the initial screen again and maybe he/she wont understand that he is given the same options to install or run live.

3. I liked to be able to skip security updates! At last, with firstboot scripts, I can bypass the installation of security updates under VirtualBox! Of course this is me while developing, don't do this in your production servers ;)

4. Useful options on login to webmin. (system page vs webmin page). Login to webmin now show the real options the user needs, and not the webmin stuff. Great.

5. I feel it faster!!! yeah, faster maybe because of the removal of byobu!!! and the network problem is solved. Hurray! Anyway the last days I started to use some screens with byobu, but I've already learned how to do the trick with the screen command.

If I come across any issues I'll post them here. Good work! I'll see when I can test the TKLBAM module. If been busy with the web patchtool! It's coming along nicely!

We'll look into the installation warnings and perhaps ejecting the CD after installation though it may not be as simple as it sounds since the installer runs in Live CD mode...

Regarding the removal of the boot from hard-disk option. This was my idea. Alon protested and said he found it useful during development. I argued that we should optimize the user experience for the common user/newbie as he's the one that needs our help the most. A more experienced user will figure it out. IMHO having just these two options make it clearer that you have to make a choice between installation mode and demo mode. The third option was fake. It didn't even do anything useful until after installation. Also, I don't like how it creates two equal but different ways of booting into an appliance after installation (e.g., remove the CD or choose the third option in the bootloader). One way is easier to explain.

I admit I just went with my gut here. If other people would like to weigh in either way it would be useful to get more perspectives.

My son suggested that if Alon (and/or others) insist on having a 3rd option you could perhaps make it "Doh I forgot to take out the CD: open CD tray and reboot"! :p

But seriously; I initially missed the option, but I think you make a good case for removing it. And it certainly makes the options available more obvious. To make it really shine though I do think you want to auto eject CD after install and/or tell users to eject the CD.

I think the official ubuntu instalation tells the user to remove the CD. That would be the way to go. Believe me people would find themselves in a loop if they finish the installation and then they are presented with two options: install or try live!

Good advice from your son! That could be the message for the TKL Homer edition LOL.

This was a tough cookie! But it has now been implemented and works whether the installation is run via the boot menu option, or the confconsole when running in live demo mode.

The hardest part was interfacing with the user after the system has gone through the shutdown procedure (filesystems have been unmounted) and right before the actual shutdown. It gets even more tricky once the installation media has been 'ejected', which means we need to cache the relevant executables and libraries in memory, make the tty 'sane'.

Oh, and of course switch back to the correct VT console where the shutdown procedure is happening.

Anyway, the cdrom will be ejected if the installation completed successfully, and the user will be prompted to remove the disc (if any) and hit ENTER, or until the timeout is reached.

We'll be releasing the final 11.0 (part I) soon once we squash all the outstanding bugs and issues, and create all the build targets. I also want to squeeze in setting of application passwords during firstboot (with preseeding support) if we have the time.

I'm going to tackle the warnings during installation. From what I recall installing the MBR generates output which is displayed in the di-live console. Are there any other places during the install that generates warnings that should be fixed?

I solved the issue globally in di-live by redirecting stderr of all commands executed to the logfile (/var/log/di-live.log). The installer will still raise an exception for bad exit codes, but warnings will not be displayed. This also provides useful debugging information when needed (no need to watch warnings flying across the screen and hope that all is well.

Basil, Anil, JedMeister, Rik, JedMeister and Adrian - thank you all for demonstrating (again) the strength of our small, high-spirited open source community. Your encouragement and feedback means more to us than you know. There's really nothing scarier than pouring so much of your heart and soul into a project and finding out that nobody cares. Unfortunately in the absence of a marketing department that happens a lot in world of free software. We're very lucky to have you guys at the core of our community.

I only wish there were more hours in the day so we could be more active even in the middle of the deepest development cycles.

I am the definition of a Linux Newbie. Look in the dictionary (they still print those?) and you'll see a picture of me trying to copy and paste the text from that definition into a Wiki page...

I'm an MCSE and systems admin for my company's network, so white text on a black screen doesn't scare me for the simple needs used under Window$ or before compiling an executable that runs under Window$. However, as soon as the real GUI ends I'm like a child in bed holding a flashlight while bunched up under the covers watching for the bogey man.

Being root for a real newbie is no small task. With almost every moment of my free time, through months of trial and error, thousands of reformats and reboots, reading Linux for Dummies and other books and wikis, searching Google, and asking a lot of dumb questions, I've been working up the courage to finally get rid of the training wheels on my test systems and use Ubuntu Server without adding in the GDE!

What makes TKL so incredibly supreme for a guy like me is that you've provided me with the end result: The target to which I can compare while I'm learning the fundamentals to get it right. If compiling a new core from scratch is "A", then where's "Z"??? The end of the rainbow is simply a construct in the newbie's mind... But with TKL PDC running in Virtual Box on Ubuntu Server, the end result is no longer abstract but is rather a real, visible, touchable, tasteful, physical thing of beauty with which to use and from which to learn.

I still can't believe all of this Linux "stuff" is completely free for how awesome it is.

Thank you so much for taking the time to write this. Until we started TurnKey I myself was part of the silent masses that benefit from open source every day but doesn't make too much noise about it.

It's incredibly motivating to get this kind of glowing endorsement from users who find TurnKey useful and share their perspective on how the project has helped them.

Newbies need our help the most so we try to optimize for their needs rather than the needs of more experienced users. The challenge is that ironically, being a bit more seasoned than the average Linux user ourselves makes it more difficult to anticipate what the pitfalls are going to be for a less experienced user.

We need more people like you who take the time to give feedback. If anyone else is reading this and thinking their point of view isn't useful because they aren't experts (yet) - please get that idea out of your head. You couldn't be more wrong.

PS: Sorry for the late reply. Lately we've been buried under our workload.

When users are running TKL in their internal network (in a physical hardware or Citrix server ), it would be nice if the TKLBAM support target location like FTP Servers and WEBDAVs or even Rackspace Cloud file (since it is more cheaper that S3). In my humble openion , there should be a "drop down list" or "radio button" to select target location type :)

Thanks for the feedback. This is a good idea. There are a zillion things we still need to do for the release, but if I have a bit of spare time I hope to take a look at this. My main concern is that supporting "manual" backups would complicate the GUI significantly. You need to take care of stuff like authentication credentials, and how you do that is different for each protocol. It's a bit of a mess.

If anyone wants to jump in and send patches that add support for "manual" mode in a way that doesn't compromise too much on usability, that would be a good starting point.

I agree with Basil Kurian, it would be great to have other target options for TKLBAM. I will be using these appliances at work and we already have an offsite backup solution in place. However, the TKLBAM interface (GUI and CLI) are much nicer than our current backup software interface, so I'd much rather use that to send the backup to our SAN via SMB which is already set for nightly offsite backups.

It would also be nice to have options like NFS and iSCSI or even over an SSH tunnel.

You may already realise. but it is possible to use TKLBAM to backup to targets other than S3. You do still need to use the Hub, part of which involves signing up for an S3 account (and providing credit card details - although you never have to actually use it).

TKLBAM will automatically use S3, but if you use the (CLI only) --address option you can send your backups pretty much anywhere. From the TKLBAM FAQ:

But you can also backup to any storage target supported by TKLBAM's back-end Duplicity including the local filesystem, NFS, Rsync, SSH, FTP, WebDAV, Rackspace CloudFiles and even IMAP.

I assume Basil was just asking for those options to be available easily from the Webmin TKLBAM interface rather than having to use the CLI.

The manual pages were rushed out when we released the very first version of TKLBAM. The content for the FAQ was written a bit later when it was clear people didn't realize you could do local backups. I'll be looking at updating the manual pages before the final release for TKL 11.0 comes out.

Thanks for the positive feedback John! There are zillion possible storage targets, from NFS, SMB, iSCSI to SSHFS. What most of these have in common is that they can be mounted to the filesystem, either through in-kernel support (e.g., SMB) to userland FUSE filesystems (e.g., sshfs).

So maybe rather than trying to support every protocol under the sun, we could just add support in webmin-tklbam for backing up/restoring from the filesystem. Let users take care of the mounting part separately.

OTOH, if you can mount filesystems you are probably comfortable invoking tklbam's cli interface. Needs more thought.

I've probably done a testimonial like this before, but I can't find it and from my perspective it's worth repeating in light of Liraz's expression of appreciation:

I hold TKL in very high esteem, in part because my reliance on their products, which are used daily in some way or another. For two weeks of each year I do a unit on collaborative writing and editing. For that I rely heavily on a VM running Turnkey's Wikipedia appliance. This year I may turn to the Dokuwiki, to keep myself familiar with different wikitext conventions. In any case, TurnKey Linux makes that unit possible. To use our Head of School's language, our IEPs are one our primary products: the quality of the IEPs in the eyes of the stakeholders can make or break us. We've dependend on TKLPatch and TKLBAM to run IEP-IPP as a virtual machine in VMware Server. Flawless implementation and outstanding services from TKLBAM. On bare metal, we run an Ampache server built with TKLPatch and installed from the ISO. That's increasingly becoming part of the technology we use in the classroom daily to serve our students' diverse learning needs. The Limesurvey VM produced with TKLPatch is used to get some quantitative data for our ed research and I hope will eventually be used for student evaluation of courses. I rely on TKL's Joomla appliance (in a VM) for prototyping sites for which I've been asked to be part of the design process. For the products alone, I'm tremendously thankful; I am dependent on them and see that dependence increasing (our VMware Server is being supplemented by an ESXi server in coming days).

But I am thankful too for the opportunity to contribute: at my level, it's been tough finding projects that can use my expertise - even when I offer to document. At TKL, I found an opportunity to contribute - it was a struggle and a reach and I've come out knowing far more than I expected. I'm more thankful for the warm welcome the students have received. I've been proud of their success, and that takes me to my next point.

The community here is for the most part outstanding. Having the Ubuntu Code of Conduct as a reminder of the culture we're aiming for is commendable. But the encouragement from others - JedMeister constantly reminding us of what we're capable of if we just reach; Liraz's honest challenges felt chilly at first, to me, but the students took the challenges and read them as very productive dares. They were spurred on by Liraz in every case, in all his ethical honesty. Liraz has gone above and beyond and offering suggestions on how to garner interest in our projects from local communities, and offering honest critiques of my write-ups. Alon never flagged in his support, always came to our aid when we found ourselves stuck in patch development (and in other areas). Alon's kindness and eagerness for us to succeed is an obvious reflection of his passion for TKL and its community to succeed.

So, yeah, thanks. Thanks for the curriculum material. Thanks for the opportunities for service learning hours (which the students would deserve if I pursued that). Thanks for the opportunity to contribute something meaningful and authentic - not only to TKL, but also to Ampache, Limesurvey, Elgg, and now IEP-IPP (over 50 d/ls now excluding direct downloads). And thanks for the appliances that serve me daily, either as instructional tools or administrative tools.

Thanks for writing that Rik. It means a lot coming from you. You and your students are a renewable source of inspiration. Every time I start feeling like maybe nobody really cares about what we're doing with TurnKey, I remember how good it felt to discover people such as yourself had joined the community, and gave back in the most productive and heartwarming way.

Is there any other tutorial other than the IRC chat training which was recorded a couple of months ago? I am really jazzed about your project and the different virtual machines which have been created. GREAT WORK...!

Sorry, I wasn't sure where to post this since it's an RC. I've been messing with the MySQL appliance, and it seems that the InnoDB storage engine, among others, is missing? Thinking something went wrong with the installer, I ran from the live cd and it is also missing from there. In fact comparing the 8.04 appliance with the new 11.0 RC, half of the storage engines are missing. Granted some were disabled in the 8.04 appliance.

Thanks for reporting this John. Alon did the integration for the 11.0RC LAMP appliance. I asked him about it and he couldn't think of any reason that storage engines would be missing, but MySQL has been going through turmoil recently with the Oracle acquisition so who knows, that could be related. We'll look into it before the final release. In the meantime, if you find out more about this problem, or others, please continue to share!

I think the my.cnf file got screwy. Bunch of default entries were missing. My hunch is when I used Webmin to edit the my.cnf, it must have done some crazy stuff to it. I will only edit from shell from now on. It removed all the innodb stuff in my.cnf. I decided just to reinstall all over again just to verify, the new install's my.cnf file looked great. Sorry, I probably posted before thinking more thoroughly about it. But, while I am here....

I upgraded to Moodle 2.0 on one instance, and boy is it slow on Turnkey, baremetal install. Moodle 1.9 is fast on the same hardware using Turnkey 11. Like 10x's slower in load times. I have not isolated where in the stack the bottleneck is. I have Moodle 2.0 running on an Xserver side by side with Moodle 1.9, and though it is a tad slower, It is only about 1.5x's slower. There is no PHP accelerator or Zend installed on the xserver. . My hunch is that it is xcache or zend, but, that is just a guess. Any ideas?

Glad you got the "missing engine" sorted out. If you have the time and can reproduce the mysql/webmin issue, then we should report the bug upstream so they can fix it.

BTW, you might want to give phpmyadmin a try, I prefer it over the webmin mysql module.

Regarding Moodle2, not sure what to tell you. Did you install it on LAMP 11.0RC or on top of the Moodle 11.0RC? I'd first take a look at the release notes, documentation and forums to see if others are experiencing the same issues. Also take a look at the apache/mysql log files.

I'm using the LAMP Lucid RC and I seem to be missing an engine that Mahara wants. Following Alon's model, I dropped to MySql prompt and got roughly the same results, minus InnoDB. I'm new to MySql so this may be a misunderstanding. But since I'm unfamiliar with Postgres (I've gotten Mahara to work on LAPP RC), we'd much prefer to work with MySql. What do I do with a missing engine? Or, if it's the case, an apparently missing engine?

InnoDB is an excellent transactional storage engine, and works great. But, I've hit issues in the past where the logfiles are considered corrupt, and therefore the engine will be disabled during MySQL startup.

I spent quite a bit of time reading over documentation, forum threads and experimenting - trying to figure out why it happens, but haven't been able to pin point the exact reason. I've tested on vanilla installations as well as populated databases. Anyway, just take care when renaming/deleting the log files so you don't loose any information.

I'm hitting the problem immediately after install of LAMP rc, so there's presumeably no data at risk. If I understand your post correctly, it's possible the corruption may happen later, once there is data at stake. With this in mind, is it your feeling we should base Mahara patch on LAPP stack instead? It'll take some research to learn how to create the db and user, set privs from a bash script, but we're up for that challenge if you think we're better off going in that direction.

A little late replying to the discussion... but I also confirmed some things. One, that the MySQL plugin for webmin totally hoses the my.cnf file. I did a fresh install and just hit save and restart and MySQL would no longer even start up. It just threw a bunch of errors. I restored the my.cnf file and it started right up.

Second, that a rename or delete of ib_logfile0 and ib_logfile1 restored InnoDB to my list of engines.

And third, the ib_logfiles seem to get corrupt during install. I setup a totally fresh VM and installed the MySQL appliance and right from the start these must be corrupted, because InnoDB did not show on my fresh install until I renamed/deleted those two logs and restarted MySQL.

Anyway, aside from this engine issue, I've been loving the new appliances. I've used this one, the core, and the LAMP. I've had no issues. Keep up the great work! :-)

No elastic load balancing support yet. 64-bit support is coming sooner, and with it you'll be able to scale things pretty far by just migrating to a bigger server instance. After that if there is demand from the community we may start looking beyond single instances.

LAPP support shouldn't take too long to add it's just that I've been buried under my workload as of late. Hopefully I'll corner some quality alone time before the final release to get it done, but remember this is an open source project and patches are always welcome.

Would really love to start using TKL with LAPP. Unfortuntaly we are not much of system admin, and do not feel comfortable doing a patch. I am definately embarrased saying that after reading how Mr. Goldman was able to teach his 11th grade class.

I received your email announding the beta - and testers needed. I go to your blog link, but I can't find the actual Files to test. Is this all on Turnkey Hub? I am wanting to test in a VM envirionment but not on the cloud.. (I read in your intro that you have VM's built).

It's my experience and understanding that the downloads of the RCs are available as ISOs on the pages of the individual appliances. So, for example, LAMP appliance RC is available here: http://www.turnkeylinux.org/lamp and labeled "Download 11.0 RC". From there, install to fresh VM. Someone will always be around to address questions, I'm certain.

TKL does not have a GUI so to speak. It is basically a Linux Server (based on Ubuntu) that only has a command line interface (CLI) rather than a graphical user interface (GUI) like for example Windows Server does.

To assist users who are intimidated by CLI or do not wish to learn the commands etc, TKL provides Webmin as a WebUI (Web User Interface). Once you have installed the TKL appliance, using a web browser (on a computer with network access to the appliance, eg the host machine if a VM or another machine in the LAN if installed to bare metal) you can use Webmin to configure yuour server.

Access Webmin into your web browser's address bar type 'https://' followed by the IP address shown on the screen that appears in the VM window, followed by ':12321'. So you would type this into your address bar:

Thanks for reporting this. A few questions to help us get to the bottom of this:

How did you install the ISO? What was the underlying target? (e.g., bare metal, a virtual machine of some kind, etc.) Did you perhaps use a KVM to control the console remotely? That is known to mess with the keyboard encoding for certain characters.

Did you use any special characters in the password? If so, could you try setting a password with only english letters and numbers and see if that has any relation to the issue?

OK, I think your point about special chars might have been the issue. Reinstalled and this time I did not use any special chars in the password-- only lowercase letters, it worked.

Additional note. I had used upper case letters for my MySQL password and that seemed to work ok.

Might want to at least update the notes to let folks know the initial password should not contain shpecial chars, the user can go back and change the root password after configuration. A small price to pay. Otherwise, these new appliances are rockin'!

I upgraded to the newest Moodle version, which fixed the issue. It seems to be an issue with the PHP version with that version of Moodle the appliance comes with. Either ou need to upgrade Moodle or downgrade PHP. So, perhaps RC 2 of Turnkey 11 Moodle would included updated Moodle version.

Thanks for reporting this. We're using the Moodle package from Lucid rather than an arbitrary version from upstream. Could you share the method you used to upgrade to the latest version Moodle? Did you just overwrite the contents of the package with the upstream tarball?

Hi Liraz, That is exactly what I did. It works great now. I tested the load using Jmeter with over 150 concurrent connections and each page only took about 1 sec to load (according to the Debug Performance reports on Moodle). I had to if course tweak the apache configuration. And this running baremetal on a 5 year old Dell Poweredge 2650 server. I really like the cool addons to Turnkey Linux.

The rails 3 console isn't working in the new appliance. The readline.so doesn't seem to be compiled. It's an easy enough fix. Download the ruby source, run apt-get install libncurses5-dev libreadline5-dev (if they're not installed, they're commonly missing from what I could see), run ruby extconf.rb form <ruby_source>/ext/readline, and then run make and make install.

Of course, would be nice if it worked by default, you're bound to forget about readline.so not being there until you need the console, and then have to go searching for the solution again =)

By installing libreadline5-dev (and its dependencies) the rails console now works - excellent catch! I've committed the fix and it will be included in all rails based appliances in the upcoming 11.0 release.

BTW, I never found the need to download/compile the ruby source after installing the required libraries.

Side notes:

The 11.0 rails based appliances use ruby enterprise edition (for performance), instead of the stock ruby packages from upstream.

You mentioned rails 3. The 11.0 appliances are based on the 2.x branch as a lot of the apps (e.g. redmine) aren't compatible with rails 3 yet. We might create a rails3 appliance along side rails2 if there is demand (and time).

I actually didn't test to see if the console worked after installing libreadline5-dev, I just followed some guide I found online, which installs it on a standard Ubuntu 10.04 rather than a turnkey appliance. Either way, great that was an easy fix, and that it'll be included in the appliance :)

As for Rails 2 vs. Rails 3, I don't think there's a need for an appliance for both. Easier would be to keep the appliance on Rails 2, and possible add a note about upgrading to Rails 3. Upgrading is easy enough, just run the gem update command.

Looking forward to the release of the new appliances though, they're a bit easier to work with compared to the older ones, especially if you want to run rails 3 ;)

So you can either set it as your local DNS server (if you have one), your router/gateway (assuming that forwards DNS requests) or set it directly to you external DNS provider (your ISP or a public one like OpenDNS or Google).

Index of /

And although v11.x TKL is heavily based on Ubuntu 10.04 it has some differences. So if you were on TKL I'd suggest that you install the Webmin-BIND module but that won't work unless you're on TKL...

So I suggest you post on the Ubuntu forums...

Regardless Apache should still work regardless of that though. Usually it has a defailt "It works!" page, but it doesn't look like your install does. Try putting an html/php file called index (ie index.html or index.php) in your document root (/var/www by default).

Otherwise you could install TKL LAMP and then start a new thread to address your DNS woes (this is a pretty old blog post).