I hope your dog gets through this.
I found this discussion about Debian 5.0 (Lenny) and have the same curiosities as the others. I need to install Virtualmin on a new server running Debian 5.0 and obviously I’m in a hurry. (you know, bigger, better, faster!)
I hope that the pooch is OK…
Not trying to be rude, but is there an ETA for this? I’m getting pretty close to having to get this Lenny server live and would rather get virtualmin than ispconfig to run it.
Thanks, and good luck to your pupster!
I don’t like to put a firm date on things, because I’m always wrong when I do. But, ETA might be tonight. I’ve been poking and prodding and tweaking all day, and I’m in the middle of a test install right now that I kinda expect to complete without error (and then the actual testing of the completed install begins, which could take another several hours, but if we’re lucky and Debian 5.0 isn’t majorly different from Debian 4.0 or Ubuntu 8.04, then it should go fast).
I’ve taken a break from that to answer this question. So, now it’s gonna be 1.5 minutes later. 
OK, so a couple of test installs and tweaks later, we are pretty much "go" on Debian Lenny. There are a couple of cosmetic issues with mail server detection, but those straighten out pretty much on their own when you click "start" on the Mail Server item in the Status section of the System Information page (after the configuration check).
I’m not going to announce it as officially supported until the couple of issues I noted have been fixed…but I don’t think there’s any harm in folks installing right now–we can fix whatever problems pop up. Just know that it hasn’t been heavily tested. Very superficial testing (configuration check passes, basic poking around looks reasonable…but no functional testing of actual hosting features has been done).
I just noticed one other bug. The suexec configuration failed for some reason, so you’ll need to edit /etc/apache2/suexec/www-data and change the first line from “/var/www” to “/home”. I could have sworn I’d gotten that one right, but obviously not. I’ll tackle it first thing in the morning.
So all you folks offering to test…have at it! Expect issues. Try not to be too repetitive in reporting them (this is why I rarely roll out "testing" releases…I get fifty reports of the same bug…often a problem that is already noted in the release notes).
And for folks not feeling even a little adventurous, it’ll certainly be more solid by tomorrow night.
One last caveat, I don’t build the 64 bit version until the 32 bit version is solid. So there is no 64 bit support for Lenny. It will come tomorrow after the 32 bit version is solid.
ok i successfully managed to upgrade a debian 4.0 + virtualmin pro to debian 5.0 + virtualmin pro in a vmware machine, 32 bit.
there are no gpl packages yet i believe so couldnt test that one.
i guess in 2 days i will upgrade my production 64 bit debian to lenny + vm pro, wish me luck 
Hello, I’m really new to virtualmin (saw it the first time 2 days ago 
), so no idea if I’m doing anything wrong…
Tried to install it on a clean freshly installed Debian 5.0 - virtual machine in VirtualBox.
I ran the script as root, here the problem:
Displaying the last 15 lines of /root/virtualmin-install.log to help troubleshoot this problem:
Now this seems strange:
sources.list is only 13 lines long… why is there a problem in the 14th line??
Thanks in advance
I should have been more clear: Virtualmin GPL gets rolled out at the same time as the 64 bit builds. There will be no GPL support for Lenny until tonight some time when the last couple of bugs I mentioned are ironed out.
That’s what I get for talking after my bed time.
Oh, I’m sorry, didn’t understand this. Time zones allow for answers even when you’re sleeping!
No reason for you to have known about my build and deploy process.
It goes like this:
Build, test, and iterate on 32 bit Virtualmin Professional repository. This takes a week or so, usually, though this stage took two weeks this time due to personal issues I mentioned earlier (and my dog is gonna be fine–she’s one of the very lucky 25-50% for whom the splenic tumor is not malignant, as far as the pathologist can tell).
Once everything looks as good as I can make it, build 64 bit packages, test that.
Once tests are passing, add the new OS to the GPL link script (which links the packages into the non-password protected /gpl/ directory tree).
Update the GPL download script to the new version that supports the OS.
Finally, update the OS Support page to reflect the new OS.
Oh, and I guess there’s the “let people bang on it for a while” stage, which usually reveals another half dozen subtle issues that need to be fixed.
nice, i scheduled the dist-upgrade of my production server for this friday
Yep, we’ll definitely be shiny on lenny by Friday.
I rolled out all of the packages for 64 bit and GPL (except for the actual virtual-server module, which I’m rolling right now) last night, and I’m doing test installs today. I usually find a few mistakes when first setting up repos, so I wouldn’t expect it to actually work until this afternoon some time. I’ll add lenny to the OS Support page as soon as I have successful test installs across all of the various arches and versions. Each test install takes about 30 minutes to an hour, including some basic QC testing.
Yeah, some brokenness in my GPL repo setup. I noticed that, too, during testing. Will be fixed soon.
Nothing like being at the forefront of technology.
Cheers!
Yep. Until it’s listed on the OS Support page, you’re gonna have to expect problems. (I’m not holding out on anybody–if it works, I like to brag about it.)
Anyway, I think 32 bit GPL is now mostly working. My quick test ran fine (a quick test involves not actually starting from a fresh OS install, so it can miss several classes of issue–saves me 15 minutes, and reveals obvious stupid stuff like broken repositories faster). I’m starting the 64 bit testing now, which will probably shake out any remaining issues, as it’ll be starting from a fresh OS install.
Now I’ve got… I’ll poke around and see if I can figure out how line 9 is malformed.
I’ve never seen that. What is line 9?
i am getting the same error except a different line number.
Now /etc/apt/sources.list is only 6 lines so guess it is something the install script is adding.
x86 GPL version
Howdy,
So, I have an idea of how we can figure out what the problem is. The question is, are you into doing some Bash script hacking, or would you like a hand with it? I’m also assuming that Virtualmin didn’t install on your system.
If you look in the install.sh script, on line 736, it says "# Install our keys".
Immediately before that line, add in this line:
[code:1]
cp /etc/apt/sources.list /root/sources.list.broken
[/code:1]
And next time you run the installer (which, again, you shouldn’t do if Virtualmin is working on your system), you have the problem version of sources.list stored in /root/sources.list.broken.
Could you then attach (or carefully paste) that sources.list.broken file into a forum posting?
If you’d like a hand doing the above, feel free to yell
Thanks!
-Eric
using the above tip, line 7 looks like this