Webmin: think of it as a web-based MMC for your Linux box. That oughta piss off a lot of people, huh? :) It's a great tool once you get it setup. Fortunately, on Fedora it's as simple as yumming it down and it'll be preconfigured for the way things are setup on that OS. Otherwise, I recommend following the docs for installation. It's as simple as putting it into the directory it will eventually run from (think /opt!), and running setup.
Now, as we know, I like to have as much of my network and systems available on the web. The problem is, Webmin uses its own internal webserver, and that server runs on port 10000 by default. Dang! That ain't gonna work from the office, and I hate typing in URLs that include port numbers. Fortunately, there's good instructions on setting it up behind or with Apache here. However, I learned the hard way that they ain't complete (once I finish this post, I'll send them an update). I use the third method provided on that page where I use Apache as a reverse proxy. This hasn't really worked very well for me in the past, but I finally figured out why and here's the solution:
Firstly, my Apache only runs in SSL mode, it doesn't accept connections on port 80. When Webmin is installed, it too sees that SSL is installed and apparently enables it in itself, so it expects you to make https requests. If you keep getting "this server is runnning in SSL mode, try https://..." after setting up your Webmin, you have this problem. To fix, firstly this should be the setup in httpd.conf:
RewriteRule ^/webmin(.*) https://127.0.0.1:10000$1 [P,L]
# ProxyPass /webmin/ https://localhost:10000
ProxyPassReverse /webmin/ https://127.0.0.1:10000/
SSLProxyEngine On
(Note, I use rewrite, rather than ProxyPass. I've left the commented ProxyPass version in place.)
You see, without that, the proxy only makes plain requests to Webmin, but it wants SSL. You also need the SSLProxyEngine On statement to enable the right requests to be presented to Webmin (also missing from the docs).
That's it. A simple solution to a problem that's been bugging me for some time.
Wednesday, February 15, 2006
Monday, February 6, 2006
Bash completion
You know what's funny? I "grew up" using both Linux and Windows. Unlike most people, I find Windows a whole lot easier to use, a whole lot more stable, and generally a better day-to-day OS. Linux is fun to play with, but I get so aggravated trying to do the simplest stuff some days. It's just not worth the level of aggravation! The latest thing that was bugging me has also been bugging me for years, I just never got around to seeing if there was a solution. Turns out a solution's only been around for a short while anyway...
Believe it or not, there IS a command line in Windows. Not only that, but if you've got a clue it can be quite a powerful tool. Since NT 3.1, the shell processor of choice has been cmd.exe. Command.com was available, but it was a DOS-emulation mode that lacked certain features. The most important of these to me being command line completion. See, I type really fast. I think the last test I took had me at about 85 wpm. Not bad for someone who can't touchtype. :) The problem is, I can't type as fast as I can think, so anything that helps me type faster is critical.
Now, bash has command completion, too, but it works significantly different from the cmd.exe version. With cmd.exe, if I hit tab, it cycles through my choices. So, if I want to enter "cd \program files", I'd hit "cd \P-tab" and be there. Bash works the same, unless there's more than one file or directory that begins with "p" in the root. With cmd.exe, tabbing again would cycle through the "p" filenames and then I could hit enter to execute the command. With bash, it would bitch, then if I hit tab again it'll list all of the choices and then I have to continue to type until I've pretty much narrowed it down to the file I want.
Personally, I prefer the cmd.exe way of doing things. And, it's not because "that's what you're used to". I've used both shells over the years equally enough to make an informed decision, and I find the Windows version faster and easier. Apparently I'm alone in this thinking because in searching for a way to make bash act like cmd.exe I found a lot of people bitching about how it doesn't act like bash. Just yet another example of how *nix nerds are incapable of learning something that they're not used to. It's that whole "projection of shortcomings" thing. :)
Anywho, I did find the answer here. It seems it's a simple (and poorly documented) matter of adding the following four lines to your /etc/inputrc. In my case (currently using Gentoo, that's a story for another day), I didn't need to make any other changes than the addition of these. I've split the configs from the comments since Blogger squinches the pages down.
set completion-ignore-case on
# Ignore case when doing completion
set mark-directories on
# Completed dir names have a slash appended
set visible-stats on
# List ls -F for completion
"\C-i": menu-complete
# Cycle through ambiguous completions instead of list
#set show-all-if-ambiguous on
# List possible completions instead of ringing bell
You can edit the file and test it using bind -f /etc/inputrc to activate your changes immediately.
BTW, if your command shell doesn't currently support this feature, that's because it's disabled by default. Here's a post about enabling it, with the obligatory clueless and wrong Windows bashing (enabling this feature does NOT cause anything to crash. It never has, it never will. I've enabled and used this feature on literally THOUSANDS of Windows boxes and never had a problem with it).
Believe it or not, there IS a command line in Windows. Not only that, but if you've got a clue it can be quite a powerful tool. Since NT 3.1, the shell processor of choice has been cmd.exe. Command.com was available, but it was a DOS-emulation mode that lacked certain features. The most important of these to me being command line completion. See, I type really fast. I think the last test I took had me at about 85 wpm. Not bad for someone who can't touchtype. :) The problem is, I can't type as fast as I can think, so anything that helps me type faster is critical.
Now, bash has command completion, too, but it works significantly different from the cmd.exe version. With cmd.exe, if I hit tab, it cycles through my choices. So, if I want to enter "cd \program files", I'd hit "cd \P-tab" and be there. Bash works the same, unless there's more than one file or directory that begins with "p" in the root. With cmd.exe, tabbing again would cycle through the "p" filenames and then I could hit enter to execute the command. With bash, it would bitch, then if I hit tab again it'll list all of the choices and then I have to continue to type until I've pretty much narrowed it down to the file I want.
Personally, I prefer the cmd.exe way of doing things. And, it's not because "that's what you're used to". I've used both shells over the years equally enough to make an informed decision, and I find the Windows version faster and easier. Apparently I'm alone in this thinking because in searching for a way to make bash act like cmd.exe I found a lot of people bitching about how it doesn't act like bash. Just yet another example of how *nix nerds are incapable of learning something that they're not used to. It's that whole "projection of shortcomings" thing. :)
Anywho, I did find the answer here. It seems it's a simple (and poorly documented) matter of adding the following four lines to your /etc/inputrc. In my case (currently using Gentoo, that's a story for another day), I didn't need to make any other changes than the addition of these. I've split the configs from the comments since Blogger squinches the pages down.
set completion-ignore-case on
# Ignore case when doing completion
set mark-directories on
# Completed dir names have a slash appended
set visible-stats on
# List ls -F for completion
"\C-i": menu-complete
# Cycle through ambiguous completions instead of list
#set show-all-if-ambiguous on
# List possible completions instead of ringing bell
You can edit the file and test it using bind -f /etc/inputrc to activate your changes immediately.
BTW, if your command shell doesn't currently support this feature, that's because it's disabled by default. Here's a post about enabling it, with the obligatory clueless and wrong Windows bashing (enabling this feature does NOT cause anything to crash. It never has, it never will. I've enabled and used this feature on literally THOUSANDS of Windows boxes and never had a problem with it).
Subscribe to:
Posts (Atom)