I had a call from a frantic user today whose sendmail daemon died hardcore. This user has a habit of playig with things first and then getting into trouble when the whole thing breaks- they aren't technically inept, they can follow instructions... and they'll remain nameless as they know who they are, and they owe me some pie now. :)
...but where I'm more of a "Learn everything about what I'm about to do before I do it" they're more of a "Play with it and when it breaks learn from that" type of person.
They weren't really amused by the problem- with sendmail dead on their box, they not only couldn't send mail from their accounts, none of their scripts (for support, sales leads, etc) were outputting either. To say they wanted it up as fast as possible was an understatement, unfortunately they weren't completely sure of what they did to cause the problem, just that they had been trying to edit the sendmail config files for better use of the 5th element for their PHP scripts, which they'd been reading from some site.
If you are playing around with the guts of any OS (linux, bsd, osx, windows, whatever) you need to have wholesale backups. But since people get told that all the time and they still don't do it, at the very least create local backups of the files you change.
Fixing the problem wasn't that hard, but first I needed to know exactly what they'd done to cause the problem: ie, the affected config files. I did this with the history command. It was pretty easy to figure out what they'd done when I saw:
pico /home/virtual/site/fst/etc/mail/sendmail.mc
and
m4 /etc/mail/sendmail.mc > /etc/sendmail.cf
You can look up what the last command does, but suffice to say it did a big nasty. But by knowing what they'd done I was able to replace the various files that were affected. If this person had followed a few rules, it wouldn't have really been an issue. Since I've already gotten mail from some of you trying the commands I've given and botching them, here are a few more unix 101's:
historywho&last- doing basic backups of a file before you modify it.
The history command
Any unix system will log a users actions into a history file, the name of which is different depending on your shell. You can change how much it remembers, or even have it set to nothing at all. You can either view the file directly, or use the following commands (or variants of).
% history
Will show you all of the commands logged into the history file, chronologically and numbered. This is per-user, ie if you are logged in as root it will show the commands executed by root, if you are logged in as an admin it will show those. What it won't do is show commands executed from within a an application. For example, you might see:
890 pico -w /etc/sendmail.mc
But it won't show you what you did to the file while you were editing it within pico. It's very valuable though, as it can show you what files were touched. Other variants that are helpful are:
% history | tail
...which pipes the history output to the tail application and shows you the last 10 commands executed. You can "% man tail" for more info, but the -n modifier is usually the most useful. Ie:
% history | tail -n 20
...will show you the last 20 commands executed by the user.
% history | more
...will display all of the commands stored, but will pipe them to more to only see one screen at a time.
For bash, history files are usually stored as .bash_history within the user home account, for tcsh they are usually stored in .tcsh_history. You want to know this because if you want to know what a user has done, you might do something like:
% pico -w /home/username/.bash_history
...for bash shell users, or:
% pico -w /Users/username/.tcsh_history
...for tcsh shell users.
Who and Last
Very basic. Whenever someone logs into a unix system, it's logged into a file.
% who
...will display who is logged into the system currently.
% last
...will give you a list of who has logged into the system over time, as well as when.
% last | head
...will give you the last 10 users who have logged into the system, you'll see your current session listed as "still logged in".
Beyond the security implications, these are important because if you know about when something when wrong, the above commands can help you figure out who may have done it. In other words, if a site starts going wonky at 2am, you might do:
% last | head -n 30
Where you see that user drunkenbatman was logged into your system at 1:30am and logged off at 2:30am. Chances are they did something you want to check out, so you would:
% pico -w /Users/drunkenbatman/.tcsh_history | head -n 20
...which would give you the last 20 commands that user executed, and can set you on the trail for figuring out what they did.
Doing basic backups of a file before you modify it
This is extremely basic, but it just doesn't occur to some people. If I was going to modify my ~/.bashrc file in order to add aliases, before you do anything you should first do something like:
% cp ~/.bashrc ~/bashrc.bak
...which does nothing more than create a backup of the file in the same directory. You could call it .backup, or .modified, but whatever you do pick something you will stick with every time you do it. For instance, you might want to know exactly what files you have specifically modified, and if you have been good about using the naming convention .bak you could use the command:
% locate .bak
...and the system would return the name and path to every file located on the system with that extension. If you see something like:
/etc/httpd/httpd.conf.bak
...you'll know you have at some point edited Apache's /etc/httpd/httpd.conf.
You have to do something like this if you are going to be playing with a unix's guts. No matter how careful you are, and or how sure you will be wanting to keep the modified file, you need to do it. Another trick is that if multiple users will be doing the above, they can each use a different suffix for their backups.
The sendmail daemon issue I had to fix today on the users machine could have been fixed in less than 5 minutes if they had done the above, instead of having to copy everything over from a virgin machine.
posted on April 30, 2003 at 06:03 PMSpent a bunch of time changing the layout of the blog around last night, just to brush up a little on CSS. When I get time I'll go through some of the terminal posts and clean them up... no promises on getting the comments areas to match the front page.
The basic config for tcsh includes auto-completion using the tab key (like using escape for bash), i.e. if from the terminal you type:
% cd ~/Lib <tab>Don't actually type <tab>, hit the tab key on your keyboard. If you hit the tab key with "Lib" spelled, the shell looks under "~/" for anything starting with "Lib" and sees the "Library" directory and fills it in for you. If there is "Library" and "Librato", hitting the tab key twice will show you all the choices.
But if you typed:
% cd ~/lib <tab>
You wouldn't see anything- as while HFS+ is case-insensitive (yet preserves case) the unix tools that ship with OSX are well, from the unix world and assume if you type "lib" that you want "lib" and not "Lib". This can get annoying straight quick for a whole host of reasons, but luckily you can add a directive to the rc.mine file we setup earlier though to enhance the autocompletion.
Type:
% pico -w ~/Library/init/tcsh/rc.mine
And on the second line (under the set prompt line code) cut and paste the below command:
set complete = enhanceCreate a new shell, and type:
% cd ~/lib
And you'll instead of getting nothing now you will automatically get:
% cd ~/Library/
Pretty nifty, eh?
The default prompt for OSX is fine, by and large, it's just a little wordy (partly due to using rendevous conventions for the host name), and I like a little whitespace between prompts to seperate them better as well as moving the current working path onto its own line to minimize wrapping for commands by giving them as much horizontal space as possible.
Click on the picture to the right to see mine, as it's what the instructions below will get you.
This one is pretty easy, from the terminal type:
% pico -w ~/Library/init/tcsh/rc.mine
You'll be greeted with an empty file, and you want to copy and paste the below into it.
set prompt="\n%B[%n]%b @ %B[%~]%b\n %# "
Be careful, there are some important spaces in there. Hit control-x and save it out, and close your Terminal.app window. Create a new terminal window and you should see your new and improved terminal prompt.
Depending on the background color of your terminal window you may want to go into the color preferences and change the color for bold to be something easy on the eyes (you can see mine to the right here).
If you're curious about customizing it more, do "% man tcsh" and down towards the bottom you'll find all sorts of other variables you can use.
Personally I use a black background with a 10% transparency, and a light blue color set as bold... generally the default colors for "ls" and such assume a black background. Plus, Apple's Aqua interface is just so damn bright that having some black thrown in can feel good.
But a nice alternative can be to set your background to a silver or light gray wit black text, I use that every once in awhile when my eyes need a break from the black.
If at any time you want to return your prompt to the way it was, simply move or rename the rc.mine file.
Using aliases in your shell help spare you from typing out frequently used but long commands such as:
% ls -ohS --color=auto
There are a few ways to customize your aliases in MacOS X, but the right way™ is to create a few custom files under:
~/Library/init/tcsh/
Now, in your finder click the home icon, and go to the Library folder, then look for a directory called "init" within it, and within the "init" folder look for one called "tcsh". You need to be looking in your user library, not the OSX library.
You may not have them- if you don't see them, use the following commands:
% mkdir ~/Library/init/
% mkdir ~/Library/init/tcsh/
You're directories are all there, now all you have to do is create the aliases.mine file which tcsh will read upon login, and load up your aliases for use.
% pico -w ~/Library/init/tcsh/aliases.mine
Since the aliases.mine file doesn't exist, you're creating it by using the above command. Now you'll want to copy and paste the below into it:
alias l 'ls -ohU --color=auto'
alias ls 'ls -ohS --color=auto'
alias . 'cd ..'
alias p 'pico -w'
alias t 'top -d'
The syntax for aliases is a little different from linux, where it would normally look something like alias ls="ls -lAo". These are just a few to get you started, you can basically add anything you want in here... it can make you a lot more efficient, especially in used in conjuction with shell scripts.
Hold down the control key and press the "x" key, type yes when prompted to save, then hit return again when it shows you the filename of aliases.mine.
Close the window, create a new one and type the "l" key (l as lucky). You should now see unordered colored output whenever you hit "l", and will move up a directory when you type "." and "top -d" whould run when you type "t".
If you aren't happy with my default aliases, from the terminal type:
% man ls
Look up the options, and add/remove to the aliases.mine file until it feels like a good fit for how you work.
Aliases are just a godsend- especially if you do things like SSH to login to servers remotely fairly frequently, or constantly type the same commands or go to specific directories all the time. Look up how to generate a private key for your server, which will allow you to login without a password. Create an alias called ssh1 or something with the command, and boom you're in.
To see all of your defined aliases while you're working, simpy type:
% alias
Mac OS 10.2 for an unknown reason ships with a version of ls which doesn't support colored output. This isn't a big deal, but having colored output for ls can make it a lot easier to quickly tell different types of files from each other, or directories from files (click the picture to the right to see mine).
Yeah, I know you've seen colored output in your Terminal.app before, in man pages and the like, but that is just basic bolding of text (which you can set a preference for under the Terminal.app's prefs).
To get actual colored output from the ls command, you have to replace the standard ls Apple ships with OSX with a more "robust" version which will return colored output to the shell when you use the ls command.
You'll need to make sure you have the Developer Tools installed from the CD that came with OSX (there should have been 3 CD's) and you're good to go. Remember, follow these instructions exactly and I'm not responsble for typos (or anything else, for that matter).
Open up your terminal, and type:
% mkdir newLSthen
% cd newLS/Cool beans, you've created your working directory so that you aren't making a mess and have changed your path so that you're inside of it.
Now, using your browser right-click (or control-click) on this link and select "copy this url" or "copy this address".
Now in your terminal window again, type:
% curl -O "(paste address here)"That is -O as in "ohboy", not a zero. Paste the url (using paste from the Terminal's menu, or the apple key plus the v key) you copied from your browser in between the quotes (yes, you need the quotes). Hit return.
Curl will go out, get version 4.1 of the gnu file utilities and write it out to a file within the current directory. You'll be treated to some nice download stats... I prefer curl, but wget works fine too if you know it.
Type these commands in order. Remember, a % symbol means you should be doing it on a new line and seeing a prompt.
% tar -xzf fileutils-4.1.tar.gz
% cd fileutils-4.1/
% ./configure
% make
./configure and make might take a few minutes depending on the speed of your computer and disk, but afterwards you'll have an updated, freshly compiled ls waiting for you. The below commands will backup your old ls, rename it to ls.bak and move your fresh ls to where it needs to be.
% sudo mv /bin/ls /bin/ls.bak
% sudo cp src/ls /bin/ls
% rehashThe "% rehash" command refreshes your shell environment, but you might want to create a new terminal window anyways. Do not close the current terminal window though!
Now, when you type the following command you'll see a nice color-coded display of your files:
% ls -ohS --color=autoSince you've replaced the ls that comes with OSX, you're going to want to replace it's man page as the options (such as color) will be different.
% sudo mv /usr/share/man/man1/ls.1 /usr/share/man/man1/ls.1.bak
% sudo cp man/ls.1 /usr/share/man/man1/ls.1
ls was just one utility you compiled, so you might as well get rid of the rest. Use these commands to clean everything up.
% cd ..
% cd ..
% sudo rm -rf newLS/
All the other utilities are now deleted. Obviously you aren't going to want to type something like that out whenever you type want to use the ls command, which brings us to aliases...
There are a few things you can do to make your Terminal.app run sleeker:
- Turn off transparency
- Turn off anti-aliasing
- Login directly
- A more efficient
top - Turn off security server check
- Auto-enable the sudo command
- Login as root
Turning off transparency
The first thing we'll want to do is speed things up in the terminal... one hard and fast rule is that if you aren't using a machine capable of supporting Quartz Extreme, disable all transparency.
The reason for this is that while Quartz makes things beautiful, it can also slow things way, way down especially if you are doing something that updates often, such as running "% top". To save time, basically Quartz Extreme takes the display layer of Mac OS 10.1 which was all software-based and takes one part of the process (compositing) and pipes it through OpenGL which allows it to be hardware accellerated.
For transparency, this creates a dramatic speedup and lowers the CPU load on the computer. If you don't have a machine capable of Quartz Extreme though, using transparency for your terminal windows, while pretty, means the CPU has to calculate the updates you see and that means that every time "% top" updates the screen the CPU has to figure out everything behind the window.
Try it for yourself- if you have a non-QE machine run top with and without transparency enabled and look at the "window server" process within top and see how much of the CPU it uses.
The option for turning this off/on is a sliding scale located under the Terminal.app's menu at:
Window Settings>Color
Turn off anti-aliasing
For the same reasons as above, using anti-aliasing in your terminal fonts can slow things way down if you don't have a Quartz Extreme machine.
Besides, 9 point fonts with anti-aliasing on just look kind of nasty... in actually if you're using something like Monoco as your font, a different Monoco is used if you are using anti-aliasing which is a little goofy. I don't even use Monoco anymore (more on that later) as I've found a few monospaced fonts which i prefer.
The option for turning off/on is under the Terminal.app's menu at:
Window Settings>Display
Think about it: with anti-aliasing on, and no QE, using anti-aliased fonts in a window that updates every 0.5 seconds is going to churn a lot of CPU cycles that can probably be best used elsewhere.
Login Directly
Whenever you open the Terminal.app or create a new window (shell) you see a message giving you your last login, the date, time, and a "Welcome to Darwin" message". FYI, Darwin is the name of Apple's open-source unix operating system that OSX runs on top of.
Depending on the speed of your computer (including cpu, disks, & subsystem) this message can delay you getting to the shell enough that it gets a little annoying.
To get rid of this simply (without changing any files) you simply want to login directly to "/bin/tcsh"instead of going through the normal "/usr/bin/login" app which then drops you to the shell.
To get an idea of what I'm talking about before you change anything, from the terminal menu select:
>File>New Shell
Now, in the same terminal type:
% tcsh
Depending on your machine, not having to look at the welcome messages (and having the shell generate them) can speed things up quite a bit. To change it, from the Terminal.app's menu select "Preferences" and click the radio button that says "Execute this command (specify complete path)" and type in:
/bin/tcsh
Create a new terminal window and it should now drop you directly into your shell with no messages.
A more efficient top
From the terminal, type:
% top
Look at top's CPU usage, which, if you're coming from a Solaris or Linux or freeBSD background will look insanely high. Ie, if you are on a 500MHz G4 it probably averages at around ~10% of your CPU cycles. You'll also see a bunch of memory information, and other things I won't go into now. Type the "q" key, leave that window there and create a new window for the next part.
The reason for top taking up so much more CPU than it normally does on other OS's is that Apple's OSX, while based on freeBSD, actually sort of slaps freeBSD over top of something called "Mach" which is microkernel (not monolithic, like all of the other unix's mentioned above). Microkernel's were all the rage for awhile, but for a lot of pragmatic reasons (mostly speed) there aren't very many "pure microkernels" out there, like GNU/HURD.
OSX isn't any different, and actually has the BSD layer running in the same address space as Mach for performance reasons. Unfortunately traversing the memory tree to display all that memory-related-goodness is a very expensive task (in terms of CPU time) in Mach.
While in many cases you'll want to know the memory information associated with processes, in many others you're mostly just interested in the processes' PID and CPU usage, so we want to cut out the memory information from top.
Use this command:
% top -d
And top should now be using 1/10th or so of the CPU compared to the straight "% top" command which you can see by comparing it to the other window you have open.
Turn off security server check
In 10.2, Apple changes the behavior of the "% sudo" command a bit- in that it makes a connection to the virtual security server process (not the case in 10.1). That connection unfortunately can take awhile, i.e. around 1 second. If you're using sudo a lot though, waiting on it to show you the password prompt can be pretty annoying.
Turning off this check will make using the sudo command an instant affair. This is a little more involved, but pretty easy. Type these commands exactly, and remember don't type the % character, that is your prompt.
% sudo pico -w /etc/pam.d/sudo
Enter your password, and you're not editing the sudo file as the root user. On the second line you will see:
auth sufficient pam_securityserver.so
Use your arrow keys to move the cursor down and add comment it out by adding a pound sign before it, so that it looks like this:
#auth sufficient pam_securityserver.so
Hold down the control key, and then hit the "x" key. When asked to save the unmodified buffer, type "yes" and hit return. It will show you a file name, leave it alone and hit return again.
w00t! Done.
Create a new terminal window and type:
% sudo top
...and the sudo password prompt should be immediate instead of having to wait for it.
This shouldn't hurt anything that I know of- it can cause sudo not to work if you have completely disabled netinfo on your machine for some reason... but no one really does that and I've never seen an OSX box without netinfo on it.
Auto-enable the sudo command
This speeds this up, as instead of having to type your password when you want to use the sudo command, it negates the check and auto-logs you in. Unfortunately, I'm not going to show you how to do it.
You can find info on the web if you're so inclined, however the security risk involved is just too great and there are very few reasons for needing to do it. It's a bad thing™. If you really need it, you should know how to do it. However, there is a time-saver below.
Login as root
While I'm not going to show you the above, often times you need to do successive commands as the root super-user. In OSX, the root user is disabled by default (which is a good thing™), so you generally use "% sudo" before your command (i.e., "% sudo ls") which runs your command as the root user after you give it your password. Very secure, but it makes you re-authenticate after a specific amount of time, which is also a good thing™.
If you have a bunch of successive commands you'll be doing as root, and are getting annoyed by having to re-authenticate, simply login as a pseudo-root shell instead of going through the hassle of actually enabling the root user.
The command you will want to use is:
% sudo -s
Give it your password, and you have a root shell. Note that this is different from Linux shells, where you would normally use:
$ su -
Bash is the default shell for Linux, instead of tcsh, so you see a $ for a prompt instead of %). When you do this, notice that your prompt changes from a % to a # as a reminder that you're root and to be very careful. Although if you didn't know that and you're doing these, I hope you're being very careful.
To leave the root shell, either close the terminal window or type:
# exit
Pretty basic stuff here, but it might help some new users get their bearings if they're used to traditional applications. When you open up the terminal (under /Applications/Utilities/) in OSX, the first thing you see is "Welcome to Darwin" followed by a prompt. The terminal is just a graphical tool to use Shells... in this case, the terminal automatically logs you into the system as the admin user.
Where you see the "%" sign, type "ls" and you will see a listing of files of the directory the shell has automatically logged you into, most usually the "Home" folder of the user you are logged in as (which is shown as a "~"). It's good to bear in mind that when you type "ls" the Terminal.app isn't following your command and showing you the list of files, but rather you are invoking the ls application located at "/bin/ls".
The ls application launches, looks at the directory you, retrieves the list of files and then displays them to the shell, which the Terminal.app then shows to you. This lets you do uber-cool stuff, such as piping commands together. For instance, assuming you haven't changed directories, type this:
% ls | grep "Pictures"
If you compare that to the output you got by using 'ls' the first time, you'll see that you now only see the directory called "Pictures". What you've done is piped (the "|" key) the output from the first application (ls) to the second application (grep) and told grep to find anything that has "Pictures" within it and display it.
Make sense? You aren't controlling the Terminal.app per se, but rather using the Terminal.app to control unix applications which then deliver their output to the terminal, which then shows you the result. Understand will make it a lot easier to wrap your head around using shells and the Terminal.app in the long run.
I've been asked about 5 times this week how I got color in my terminal, as well as my nifty shell prompt... it isn't that big of a deal, you just have to create a custom rc.mine, an aliases.mine and replacing Apple's "ls" with one that supports color. The last is probably the most difficult for those who aren't used to Linux/Bsd/Solaris/OSX.
All this will work fairly easily, with the prerequisite that you're on 10.2 and have the Developer Tools installed which will give you GCC (a cross-platform compiler) and other goodies. You don't need GCC if you will just be customizing your shell prompt or creating aliases, but it's good to have anyways.
This also assumes you are using the OSX/freeBSD default shell, tcsh. If you are using bash, specifics will differ. Bash is generally what you want to use for scripts, but most people will use the default tcsh.
So, to clarify, you need:
- To be using the default shell, tcsh
- Be using Mac OS 10.2
- Have the Apple Developers Tools installed, which comes with OSX on a seperate CD
For future reference, when you see the "%" sign, that stands for the tcsh prompt... don't actually type it.
Sendmail is kicking my ass tonight. There's been no exploits on the sendmail bug that's been making the rounds, but I patched anyways the other day. One of the boxes had been problematic, with sendmail processes going a little haywire (redhat linux/7.2) with no load to speak of... cleaned the ques, checked the obvious... sendmail was just having issues approximately every 4 hours.
To tide me over for a few days I just made a cron script that would shut it down and restart the sendmail process every 3 hours... well, it worked well for 2 days, but not the 3 I was hoping for.
Sooo... had to go back to -rpm sendmail and reinstall from scratch, which caused a problem with some special config files... but everything is back up and seems to be testing well as of midnight. Trying to decide if I should hit the sack and get on my to-do list bright and early, or try to make a decent dent it in tonight.
There's an old quote, "If all you have is a hammer, everything looks like a nail." which has been sticking in my head lately.
Often the right "peg" (tool/technology/person) for the hole (void, problem, need) isn't what you have or are most familiar with, but rather something else. Being aware of that is the hard part, and being able to mentally take a step back.
When dealing with technology/solutions/problems, you need to be as detached and independant as possible. But when you're dealing with people, that isn't really as easy as it sounds or even desirable, if not impossible.
Yeah there's a reason why I'm talking about the above, and it's all sparked from a conversation with a friend a few days ago... and if I explained more it would make sense. Just don't have the time or inclination to do that.
I made a gaff today- having to do with pegs and holes. I guess we'll see how it turns out.
No word back from Communitech regarding the issue I was having (which is ok, I solved it) but they did sent out an email to their clients detailing some of the issues they were having... and it looks like their forums are back up.
From talking to some of their clients, the story as I understand it is that they were just bought by Interland and in moving a lot of the people over they've really just dropped the ball.
Going to give it a few weeks, and if there are still major problems, hopefully the stuff will be moved. I'd like to avoid that, as they probably have a hundred machines whose settings would need to be changed (basic pop/smtp stuff) and that's a hassle I just don't want to mess with.
It's been two years since your accident tomorrow, and you aren't forgotten. I think you'd be proud of your family and how they're doing, and I hope that wherever you are now you know we love and miss you, and that you touched a great many lives for the better while you were here.
Wherever you are, I hope you are happy and at peace. Godspeed on whatever journey comes after this one.
A client needed me to install some basic scripts onto their site last night, as they have a meeting today. Things didn't need to be perfect, or have that site's look and feel- just had to have some filler data and have it working as a "proof of concept" type of thing for a dog and pony show.
I know the scripts pretty well, and have installed them on multiple servers with no issue. Turned out they have used Communitech.net as their hosting provider for a few years, and God I hope that changes soon.
These folks just have real, serious issues. What should have taken an hour total ended up taking almost five stupid damn hours. Wish I was kidding, but damn am I in a foul mood and damn if I'm not going to get them switched away as soon as possible.
Admittedly, I didn't have perfect information: just the control panel url, and customer id/pass. But still, shouldn't have been a big deal. I simply needed to know five things:
- The path to Perl
- Current mySQL database name and user/pass, and ability to set higher grant permissions for that user if need be.
- Local path for files, ie /home/virtual/mydomain/public_html/
- What perl modules were available, to check against the list of needed modules.
- FTP user/pass, or SSH user/pass
I'm not a complete newb when it comes to this, and I figure through the information in the control panel, and the forums and knowledge base on their site getting the info I need shouldn't be a big deal.
So... without further ado I check out the site in question. Sorta slow, yet not very complex... figure it's just my cable modem acting up again (Comcast just took over... not so good) and dont think much of it. Log into the site control panel via Safari, which works well but its dead slow. Switch to Camino... a little faster, but it crashes a few pages in. Mozilla is a little faster yet, and handles it fine but it's still dead slow. At this point I'm just assuming that whatever the hell they're using for a control panel (they seem to be a Sun shop) is heavily IE-oriented and doens't play well with other browsers. No biggie, kinda used to it.
Poke around, and the information on Perl modules is very easy to find... which means I don't have to worry about perldiver.cgi or some such, as I don't want to go through the hassle of everything else if the modules needed aren't available, as since it's a virtual account I doubt they'll let me head over to cpan and make them. All the modules I'm after except one are there, and it's more of an extra, so things are ok at this point. Path to perl is right there to. Lookin good.
So, onto mySQL. You can add databases and users (and grant access for the user) fairly simply. No worries there. But before I go mucking about with the dbase, even though its not being utilized heavily I want to do a dump, just in case.
Next stop, SSH so hopefully I do a dump of mysql, wget the files in I need, untar and pico -w them to where they need to be. No such luck. Oh sure, there's an SSH section, but the links aren't working correctly and you can't get to the setup area. Assume there is something wrong my with my browser, so I hop to a machine with IE. No go. Find some other broken links (such as their forums), have someone else double-check to make sure I'm not missing something... no go.
I do find a different username (not numerical) listed within the control panel, and start using that to see if I can SSH in. Took awhile, and had to use the IP address and not the domain, but I got in. Slower than hell. IE, my machine and network is pretty much idling and its taking a quarter to half a second for each character to return. I'm getting pretty disgusted at this point, so I disconnect and run a traceroute. Seems fine, normal amount of hops and latency is ~50-80ms per hop, with one spike at 120ms. Not a big deal. I am realizing that their site number is above 900, and hope to god they don't have over 900 sites on this one Sun box (pluto).
Have a feeling they're just piling it on to eke out more profit per server, to the point where its overloaded. Ah well, even if it's annoying it's a problem for another time. It's a bit after 2am now and I'm getting a bit annoyed, as I should have been in bed an hour ago. Pot of coffee to the rescue, and I'm a little rosier.
As it turns out, getting in via FTP is a little different than SSH, but wasn't too difficult, just trying combinations (IP, numerical username, domain, other username, etc) and I'm in. No worries, and ftp seems to be a little zipper than SSH. No worries. SSH is so slow I just edit the files locally, then put them where they need to be. Then the weird ass permissions stuff starts. I don't have an explanation for it, and used two different programs, and finally SSH'd back in and chmod'd them. I'd set to 755, then select and check them, then come back 5 minutes later and they'd be 000 or 444. Just weird. They seemed to become tame after 20 minutes, so that was that.
Last thing I needed, since the scripts involved a bunch of uploading was the path to local files. Normally this would be something like:
/home/virtual/site10/var/www/html/$pwd was disabled for the account, so I was off to their site as well, what hosting company wouldn't have the path to their files up online? Have to log into their site to get to the real help, but no worries... except it wasn't there. No forum, and the knowledgebase was all goofy. I did a quick google search for + "communitech.net" "path to files" hoping to get lucky... but no such luck. Slogged through their site again for awhile, but there really wasn't much there and they really seem to want you to call them. Support information is scarce as can be, but their support number is everywhere, along with taglines along the lines of "real human support".
I just don't get that. Seems to me it's a lot more efficient (and cost-effective) to try to reduce the actual contact you have to have with customers by letting them get what they need. Just sort gave me the willies, as damnit when I buy a VCR there is a booklet with the basic things you need to know to program the thing right there- I don't have to call sony to learn the magical button combo that turns off the blinking 12:00.
I end up spending more time than necessary going through and making sure I wasn't just missing something...
...so I gave up, have it their way. They aren't the cheapest game in town, and they offer 24/7 support via 800 number, so lets use up their dime. Long button pushing (1 for this, 3 for that) later I hear a ring, then a disconnect. Go through it again. Talk to a guy for 5 minutes, explain that I need the path to the local files to input into a few cgi's... he's very polite, verifies I'm supposed to have access to the information, decides I should, and then puts me on hold while he looks it up.
I'm treated to some nice muzak for 3 minutes or so, and he comes back on saying "thank you for holding I'm waiting to talk to someone on another line who I think will know", and sends me back to the muzak while he waits. Disconnect. Call back, go through the whole thing again. At this point it's after 3am, and I'm terrified of being put back in muzak land. I could rant for an hour about automated phone systems, but I'm pretty sure everyone hates them... so what's the point.
So I try to chat him up for a bit, hoping he'll not want to be rude and won't put me on hold again while he waits for his higher up to finish. I tell him I've been trying to access the forums, and that they're not working, and the KB archive seems to be having issues also (blank pages returned). He feigns disbelief, and assures me that the forums are most definetly up. He finally admits defeat when I politely ask him to actually type in the url and log in... and he gets the directory denied error also. Nothing accomplished, just trying not to get disconnected again.
Seems to work, he's a nice guy, and if they just had the local path to files on the damn sheet he was reading from I'd be all set. The 2nd level tech comes on, and I'm close. I can just feel it. All I need is the local path, input some filler data, make sure things are working and I'm off to bed. I'm even getting a little cheerful in anticipation. I'm not normally one who looks forward to sleep, but it's after 3am now and the pots of coffee, nicotine and frustration are taking their toll.
Still, it isn't as though it was the tech's fault he was hired to read from a sheet, so be polite, don't take it out on him... but keep him there to keep from getting disconnected as we're close to a solution.
Turned out to be a bit of cruel joke. The 2nd level tech can't seem to wrap his head around the fact that /public_html/ was not the path to local files, and I'm dutifully doing my best to explain the concept to him. Conversation goes something like this:
Tech:
No sir, /public_html/ is the public path to files. Everything you put in there is what someone will see when they view your domain name.
Me:
I understand that, but that isn't the path I'm looking for. I need the path that apache needs to traverse in order to get from /cgi-bin/ back to /public_html/. Normally this is something like (insert path explanation)... and I need the files to be generated into the directory /upcoming/ in /public_html/. These are the path variants I've tried, and this is the error message I'm getting... so I don't have the right path.
Tech:
No sir, all you have to do is use /public_html/, that is the path to files. See, your /upcoming/ directory is already there, and the error is saying it can't create the file as no such file or directory exists, so you need to put your file within /news/ and you'll be set.
Me:
...
Tech:
Sir?
Me:
Sorry, I think we're miscommunicating. I've tried /public_html/, as well as /home/public_html/, but I believe I'm missing a path component... the /upcoming/ directory is there because I put it there, and the error is saying it can't find the /upcoming/ directory where I'm saying it should be. I just need to know the local path to /public_html/ from /cgi-bin/.
Tech:
Oh, you just need to use /public_html/ as that is the first thing you see when you FTP in.
Me:
*sigh* Ok. I know that is the first thing most people see when they FTP in, but that is because they are being dropped there. Apache itself has to traverse back up the tree and back down to /public_html/ to get to the directory I need. Again, normally this would be something like...
Tech:
Oh, so /public_html/ isn't working? You're sure? That's what it should be.
Me:
I'm so very sure. Here are the files themselves- here is the login, here is the command to run them, and you'll have a better idea of what's going on. Remember that with a virtual account the domain name itself is just a pointer, with the domain being within a sandbox holding mail, stats, etc... and the public html folder. Apache needs to know how to get from one directory to the other, and if you are going out from the cgi-bin you can't have a relative link.
Tech:
Oh. So /public_html/ won't work?
Me:
Exactly. Is there someone there you can ask what the path to local files is, that's all I need.
Tech:
I will have to advance it up to the next level.
Me:
Ok, just set the phone down so I don't get disconnected and I'll wait while you do it.
Tech:
There's no one here though, they will have to call you.
Me:
But it's past 3am, and I have to have this out in the early morning.
Tech:
I'll make sure they get it and get in touch with you before that.
Me:
...but it's already almost early morning, and like you said, no one is there.
Tech:
But they'll call you.
Me:
Do you have a timeframe?
Tech:
No, but I'm sure it will be as soon as possible. Let me double check your contact information.
Me:
*sigh*. I appreciate it. Thank you for your time.
This obviously wasn't a solution, so I did what most people would do... drilled google down as far as I could go. Unfortunately for as many sites as they appear to have on their servers, they aren't mentioned much on the web in regards to their scripts.
I got lucky though, and one of their resellers actually had it up in their FAQ... took a long time to find it though, and was fairly simple, involving the domain of the account (minutes the .tld, which was odd). Bingo-bango, done and working fine, albiet very slowly.
I probably could have been smarter in my searching, ie in figuring out exactly what OS they are running (assuming solaris) and searching more on its specifics rather than Communitech's, but their control panel was a little odd and who knows what custom thing they're running and I really wasn't in the mood for a wild goose chase.
The moral of the story is simply that there are a lot of good hosting providers out there, there's simply no reason for (barring some odd things like your provider registered your domain in their name and won't let you leave or access your files or something) for not checking out the competition and getting the best performance, documentation and service you can find.
Oh, and please, for the love of god, something has to be done about these phone systems. I suppose they would give some people a sense of purpose in clicking through options instead of just being on hold, but when you have to go through them over and over (they seem really prone to disconnect) it just gets to be a joke.
And I swear it isn't as though the options you select really seem to make much of a difference farther down the phone chain- as you always end up having to repeat the information anyways.
For the record, they didn't call. But at 6am after an hour and a half of sleep I did get an form email via their support system (ie, it gets generated whenever a tech puts it in) letting me know that it had been escalated to their specialized group and they would be in contact as soon as a solution had been found.
Escalated. to. their. specialized. group. for. the. damn. path. to. local. files!
As of 9:30pm, no contact.
*sigh*
...has made me it's bitch.
I swear to god, it's hit and run on my machines. I have an iBook that just won't print no matter what I do, and I've tried everything (yes, every tip and trick you can think of more than once) short of Apple's answer of "reinstall and only patch up to 10.2.4" which is something that just isn't going to happen right now, considering I've had to reinstall 10.2.4 on that machine twice.
The powerbook is running fine, but the iBook just has massive issues with sleep, printing, the whole bit. It randomly attracts kernel panics like no ones business.
Just getting kind of sick of it. Right now my firewalled PC has about three times the stability if not more, with the caveat that I don't use it for email... which with the caveat of outlook could hurt things. Sad.
I had the exact same thing happen to me, even up to Apple finally repairing the machine under warranty. Weird.
The battery is now working again at least, but still the trackpad cursor disappears every so often (requiring a restart) which Apple says is a known bug and they will have a fix out for it (this was oh, about a year ago).
It's doing ok, the only real problem I'm having with it now are lots and lots of random kernel panics. Done the peripherals check, clean install, memory check, etc. Nothing helps it. Seems to happen most often on a wake from sleep.
Again, as much as I like macs there are very few people to whom I would actually recommend one to right now.
Yes! Mozilla.org posted the new development roadmap, which among other thing says:
Switch Mozilla's default browser component from the XPFE-based Navigator to the standalone Phoenix browser. Note: the Phoenix user interface is defined entirely using XUL. So in preferring Phoenix, we are not deprecating XUL. We are demonstrating how XUL is a sound basis for fast, cross-platform applications such as Phoenix.
and
Continue the move away from an ownership model involving a large cloud of hackers with unlimited CVS access, to a model, more common in the open source world, of vigorously defended modules with strong leadership and clear delegation, a la NSPR, JavaScript, Gecko in recent major milestones, and Phoenix.
This is very very cool. There's already an experimental Pheonix build for OSX, but it really isn't ready for prime time and was more of a "proof of concept" that they could get it over (ie, it crashes all the time on my machine). I don't think it will actually be called Pheonix anymore, due to legal issues with the name... but minotaur was a cool name for the mail app so hopefully they'll find something equally as cool.
As it is right now, when you use Mozilla you have a mail client, HTML composer, chat application and some other stuff that most people will just never use. This not only increases resources while running Mozilla, but makes downloads for the app itself much higher than they need to be. Seperately, if you do use the mail client (now called Minotaur) if Mozilla happens to crash (or vice versa) only one app will go down, not both. Very very cool.
It'll be interesting to see what comes of the new, more structured development model... i haven't spent a huge amount of time looking through the Mozilla codebase simply because it seemed to be a free-for-all of used code, might be used code, code that will never be used but they'll keep it around anyways, and code that someone hopes will get it...
I've been very positive about Safari, but just can't take it anymore and have switched back to Mozilla. I checked out Chimera Camino, but it also won't work with a bunch of yahoo stuff, or movable type (uploading files, etc...) or a bunch of other sites I have to work within every day.
In all honesty I really like the new builds of Mozilla, they seem faster (in rendering) than either Safari or Camino, and work with almost every site I have to use often (only one left where I have to use explorer). I had to get a 1.4a nightly so that i could use themes (orbit or orbit retro) due to this bug, and while there is some weirdness with managing bookmarks by and large I'm grooving on it. I so missed stored passwords. And it really does render a whole slew of pages (much of them SSL-based, or very complex) much, much faster than Safari.
The only thing that really annoys me is that url's requested by apps don't open in a tab (such as netnewswire) and I really wish I could have some sort of auto-download folder like Safari has...
I know I've been positive about Safari, but I hadn't really put it through its paces. It just doesn't feel "right" to me, everything from the metal interface to the way its tabs work, and it is missing a bunch of features I just really need.
I was really worried about the resources Mozilla can use, compared to something like Safari, but in all honesty 1.4+ seems to have made huge strides in that area as it doesn't take up much more mem than Safari while running.
The metal interface of Safari just has to go. After I used it for a long, long time it just felt heavy, cumbersome, and well, it just didn't feel right like it does for iTunes. It hasn't even reached 1.0, and it was starting to feel like a cluttered, hacked and tacked on mess of an interface, rigid where it should be loose and loose where it could benefit from being more rigid.
Just my humble opinion, of course, and I'm sure lots will disagree with me.
