Automate MySQL database & user creation
Continuing from the Apache virtualhost article, this is another script that automates the creation of a MySQL database and a user with all permissions to it.
Continuing from the Apache virtualhost article, this is another script that automates the creation of a MySQL database and a user with all permissions to it.
Virtual hosting is one of the most important things to happen in web hosting over the recent years. It allows a single IP to be associated with multiple websites. Though there are many panel solutions that offer virtual host management, it's nice to know what's going on and even better to actually be in control. The tradeoff is that small mistakes can cause all of your sites to go down until you fix them -- unless you automate.
I just setup a development enviroment using Debian as my distro. I noted however that when using tasksel (the wizard during installation) to install an SQL server, I got PostgreSQL. Nothing personal with it, I just haven't used it much, and thus hate all the non-MySQL behaviour quirks it has. It just had to go.
Building a new site today assumes that everything social should come with the box -- not even in it. Within the first question a client asks is how this whole twitter-thing works, and how he can use it. Of course Drupal provides modules to integrate with these, but what if you're stuck on a host "playing it safe" and sticking with PHP 5.1.6 ( that is, all RedHat, CentOS providers that won't use custom compiled packages )?
For all (well most) of your console compressing / uncompressing needs, tar is there. All you need to do is set it to work.
Assuming you've spend anything more than an hour with a Linux server on the developer/admin side of things, you've most likely bumped into the filesystem permission scheme.
There have been a number of times when I've realized that I must restart some service at a production server. In such enviroments, restarting a critical service ( e.g. MySQL on a webserver ) in a production enviroment is simply a no-go during hours with traffic. And since the lowest possible traffic is during morning's early hours, you can either "schedule" your service restart to occur after going out with friends for a couple of beers, be awake {until|at} that time.... or simply let your server know that something needs to be done at that time.
So you're enjoying your Webserver features, when you realize you need to change something pretty basic, such as the memory limit of PHP. That of course, is set through php.ini ... but where is that file located?
Well, at least the login part. For some (very) weird reason, some distros think that everyone is part of some huge, corporate environment -- thus making Kerberos and GSSAPI logins the default methods.
Is there a problem with that ? Well, not directly - you only need to wait until SSH can understand that login just ain't gonna happen that way, and fallback to the good' old username/password asking. The real problem is that it can...take...AGES!