In an earlier article, I mentioned that MAMP Pro was still the best native GUI for managing web services on the Mac, now that macOS Server will no longer serve up those patchy services. After we cover the management in this article, you’ll likely understand why it comes it at $59.
So you’ve installed MAMP. And you need more than the few basic buttons available there. So MAMP Pro came with it and you can try it for a couple of weeks for free. When you open MAMP Pro, you’ll see a screen where you can perform a number of management tasks. This is a more traditional side-bar-driven screen that will look like what Server Admin might have looked like before the web services screen got simplified in macOS Server.
The Hosts item in SETTINGS will show you each host installed on the server. Think of a host as a site. Each web server can serve up a virtually unlimited number of websites. You can configure an IP binding to the site, or hav
If you click on the plus sign, you can add a site. In this example, I’ll add www.krypted.com and then click on create. When doing so, you can configure a database for each site (e.g. if you’re doing multi-tenant hosting), build a site off a template, or select a root directory for the site.
The Apache tab of each host allows you to configure host-specific settings, including enabling options for directives such as Indexes, Includes, SymLink following, and CGI. More options than were in macOS Server for sure. You can also order allows, allow overrides, add new directives, set the index (or the default page of each site), add additional virtualhosts (such as krypted.com for www.krypted.com), and add a server admin email address.
These were Apache-centric settings for each host. Click on the Nginx tab if you’re using Nginx instead of Apache. Nginx is a bit less “patchy” so there are a fewer options here. But they’re similar: Configure an index, add parameters, and a feature not available in the GUI options for Apache: allow or deny access based on IP.
The SSL tab allows you to generate a CSR, upload the cert and key file, and force connections to use https.
The Extras tab allows you to automatically install standard web packages. For example, here we’ll select WordPress.
Click on the Databases tab. To connect a site to a database, enter the name of the database when prompted. Note: the site itself will need credentials in order to connect, and if you’ve setup an “Extra” in the above step, the database will automatically be configured.
Next, let’s configure the ports used by the web servers. The previous settings were per-site. The rest that we cover in this article will be per-server, as these are global settings applied to the daemons themselves. Each of those services will have a port or ports associated with them. For example, the standard web port used is 80 or 443 for SSL-based connections and the standard port for MySQL is 3306. For publicly-facing sites these would be the standard ports, and given how common they are, there’s a button for “Set ports to 80, 81, 443, 7443, 3306”. Otherwise, you can enter each independently. Because the attaching of daemons is done here, this is also where you configure the user that services run as, as well as when to start the services and truncate log files.
The Editor option configures how the editor appears, which we’ll cover last in this article. The Editing option manages how the editor works (e.g. things like tabs, autocompletes, etc.
The Fonts & Colors tab allows you to select each color assigned to various types of text.
The Default Apps tab allows you to configure which app is opened when opening each type of file supported.
Again, we’ll look at the editor later in this article. First, let’s finish getting the web server setup. Click on Apache. Here, you can load new Apache mods you download from the interwebs. I should mention that an important security step in locking down a publicly-facing web server is to disable all of the mods you don’t absolutely need.
At the bottom of this screen, there’s also a handle little link to the directory with your logs, so you can read through them if needed.
The Nginx option underneath is similar. Access to log files is there, as is the ability to enable installed Nginx mods.
The MySQL option also provides access to some straight-forward command-line options, but in a nice GUI. Here, you can configure a root password for MySQL ( which does this: Reset A Lost MySQL Password ), enable phpMyAdmin, MySQL Workbench, and Sequel Pro-based administration, enable network access to the MySQL Service (using ports configured in the Ports section of the app) which I cover at Allow Remote Connections To MySQL, and view logs.
The Dynamic DNS options are cool. Click there, and if your web server is behind a DHCP address, you can configure a dynamic DNS service including DNS-O-Matic, no-ip.com, dyn.com, easydns.com, etc. This way when you reboot and get a new IP address from your ISP, it’ll update the service automatically.
Memcached is a distributed memory object caching system. It’s used to make sites appear faster or to distribute caching between servers for systems that, for example, get clustered. It’s included here for a reason, I’m sure of it! Either way, I actually use it for a few things and like the fact that it’s there. To enable, simply choose how much memory to give it, configure the logging level (usually low unless you’re troubleshooting), and gain access to logs. If you check the “Include Memcached server in GroupStart” then memcache will fire up when you start your web services.
Click postfix. Here, you configure your server to route mail through an email account. If you run this from the command line, you can also configure your server to be a mail server; however, when you do that you’re likely to get mail bouncing all over the place. So if the server or a service on the server is supposed to send mail, it’s usually best to route through something like a gmail account.
The Languages section allows you to configure how PHP, Python, Perl, and Ruby work on the server. For PHP, you can configure which version of PHP is installed, configure a version of PHP for hosts, enable caching (different than memcached), enable a few basic extensions (I’ve been playing with oauth a lot recently), choose logging options, and have a simple way to see the logs.
Since you’re running on a Mac, you already have Python, but if you click on the Python option, you can make the version of Python bundled with Mac is 2.7.10 instead of 2.7.13.
Click on Perl to do the same.
Click on Ruby to do the same.
The editor is also pretty easy to use. Simply use the plus sign to add a file you’d like to edit. Keep in mind when browsing that everything MAMP Pro needs is self-contained in the /Applications/MAMP directory, so it should be pretty easy to find files for editing.
And that’s it. This seems like a lot of stuff, but between sites like ServerFault and other Apache/Nginx articles, you’ll likely find most of the things you need. It’s worth mentioning that I consider this another baby step to just managing Apache using config files. macOS Server tried hard to reduce the complexity of where different settings and options are derived from; MAMP Pro makes no allusion that web server management should be so simple. That’s one of the things I like about it. It’s like you went from riding in a buggy on the back of a bike to riding with training wheels. The more you know, the better off you are.
Apparently it’s out. I’ve been botting games for years. Botting is my way of coping with an addiction to games. I simply cannot help myself. I start playing a game and I just cannot stop. And that’s where bots come in. Over the years I’ve found a number of ways to write bots. It started with easy little web scripts and has now morphed into a full blown SWT library framework that spans multiple games, multiple platforms and runs around 20 instances from my home network at all times. But when you start writing bots, you enter into a new kind of game that is a game in and of itself: how not to get caught. Developers of these games mostly hate bots. Other players mostly hate bots. Even I hate bots when I encounter them in the wild (or Wildy according to what game you roll with). Most consider using a bot akin to turning to the dark side, and writing them to be synonymous with being the evil emperor. And with everyone out to get ya’, you have to be careful. Here are the top 10 tips and tricks to not get caught that I’ve picked up along the way: 1. Never bot using your main
Addictions hurt ourselves more than they hurt others. We often get attached to our main character. So be good to yourself, have a main that you play when you want. You can convert a bot to a main later, but bots get banned. So don’t bot with your main and make sure to keep the equipment from different characters separated.2. Never bot when you can impact the user experience of others
Our addictions hurt ourselves, but they often hurt others even more. If you are coping using bots then do not harm the user experience for others who likely have a healthy relationship with the game by stealing resources that they need. The way I like to handle this is by telling my bots to simply log out of the game, or run away and do something different any time another character comes close to me. If there are no other players (or moderators) to report you for botting then did it happen?3. Think Globally, Act Locally
The economies of these games can be very complex. When your bot flaps its wings there very well may be a tsunami in Deepholm or Varrock. The impact of botting is actually the foundation for many a global economy in many a MMORPG, whether the creators want to acknowledge it or not. But not my bots. My bots use or destroy all of the resources that they consume on a quest to either stockpile Millions or Billions of gold or (way more likely) to earn massive4. Do not bot for too many concurrent hours
Sure, you may have gamed for 20 hour stretches. But you can’t do it too much, or you start looking a little like Bela Lugosi. Chances are, if you’re writing a bot to play a game for you, you’re on a road from addiction to functional addiction. Don’t expect your bot to do something you couldn’t. Again, it’s about mimicking human behavior here…5. Do not use a bot to improve the same skill for too long
Improving a given skill becomes repetitive. It gets boring. Humans have to work on different skills after 4 or 5 hours of laboring mining for gold or throwing fireballs at orcs. It’s just the way it is, we’re human. But a bot does what you tell it to; over and over and over until it runs out of memory or you tell it to stop. Therefore, if you want to mimic human behavior then tell your bot to stop after it’s been running for a good 4 to 5 hours. I usually like to write bots to run my bots. These little controller programs will instruct the character to train one skill for a random interval somewhere between 4.5 and 5 hours and then to move on to another skill. Since many skills are dependent on other skills, this often makes the most logical sense (ie – you have to mine gold before you can smelt or smith it).6. Account for random events
Developers of games do not want you to bot. It just so happens that there are a lot of bots running loose in any game (yes, even the silly Facebook games). One of the main ways that the developers try to catch you is by introducing random events. If your bot gets stuck on too many random events then you can pretty well assume you’re close to getting banned. I usually address this by having my bot pause, run special mini-game bots for the random events and then upon completion of those bots, unpause. Most games will have a maximum of 10 of these random events, with the most annoying part of solving them being waiting for them to happen. But if you find that your bots have high ban rates then this will help to keep that in check!7. If you buy or download bots, make sure they’re from a trusted source
One word: virus. Next time I hear a Windows XP user complain about getting a virus ’cause they downloaded shady software from an untrusted source I’m gonna’ pop. Do you really think that bots aren’t someone grey area stuff as it is. But addicts know the blame game. Just don’t blame the author of the malware when you did something stupid.8. Be social
This is where a bot-net can come in handy. But doesn’t that conflict with the rule of botics #2? No. You might really have a problem when you write bots to specifically talk to bots. When you have multiple bots communicating you have effectively built a bot-net. At this point, if your addiction gets too much worse you may find yourself hitting rock bottom and writing different types of bot-nets for shady and dangerous Russian’s (no offense to Russian’s but if you’re gonna’ harbor them you kinda’ have to own the repercussions).9. Do not attach your name or typical handle to anything having anything to do with a bot
Do not trade ill-gotten items (you’re kidding yourself if you don’t think that botting is ill-gotten anything) to your main. Do not call the bot CharlesEdgeBot or whatever. Don’t use your email address or anything else that can help to track back to you. I’m not saying you have to go so far as to use Tor to anonymize your IP, but I do… 8D10. Never, ever, ever tell anyone else that you are botting
When other people see your scores and your gear, they’re going to be envious. Writing scripts can take a lot of time. But so can playing the game. Nothing is going to get someone to report you faster than bragging about how awesome you are, then in a sad effort to pretend that you don’t have a problem, tell them you botted and have them go from envy to anger in short order. Remember, other players can spend months if not years building a character and be way behind you when you are botting. Put simply, players who don’t bot despise players who do bot and will report you. Keep your addiction to yourself and you may just keep out of trouble…As you find success, you may find yourself going so far as to sell your ill-gotten equipment, gold or even characters. At this point, you have found your way to the dark side. But hey, at least we have cookies…