Highest Reputation Content

We're now running on Invision Power Board 3.0. I've customized a lot of the skin, but I believe there's still a bunch of things I've overlooked. Please post in this topic if you see anything out of whack. I'm still not 100% happy with how it looks, so there will be some ongoing work to continue tweaking the look.

Beyond the skin, there are at least two new interesting features.

• Facebook Connect is now supported as a login method. You can either create a new account using it or link it to your existing account. This might be an easier way to log in for some and it's pretty neat. Be sure to become a fan of ASO on Facebook, if you haven't already.
  
• You can now vote up or down posts on the forum. This contributes to the "reputation" of a user, so quality posts are rewarded.

There's a bunch of other little goodies around too. Take it for a spin and feel free to let us know if you don't like anything set up the way it is.

Added the following Wiki entry: Use Your Domain With Tumblr

Indeed, as was stated. However, that's a 24 hour wait (and it hasn't yet arrived, although it hasn't yet been 24 hours, and I've seen elsewhere on these forums that it sometimes surpasses 24 hrs). What is one to do during that time? You don't want someone to just feel "stopped" at any point on your website, but have things to do and see. And I'd tend to think that the forums here would be a great place for people to browse around till they "naturally" felt like they were done, rather than being arbitrarily stopped.

The MySQL maintenance on natal is now complete and the MySQL server is back online. We are continuing to see intermittent performance issues while we work on a permanent solution but all sites should now be back online. If you are having further issues please open support ticket and we will be happy to help you.

The MySQL maintenance on natal is still ongoing. Once we have further information we will keep you updated. Thanks again for your patience.

We are currently running emergency maintenance on the MySQL server on natal.asmallorange.com server. The server itself and all other services will remain online during this time. We will keep this thread updated with any updates. Thank you for your patience.

We are experiencing the same thing on sara. No update since around 1pm... and no backup plan for an attack. Even massive worldwide attacks on sites such as amazon or tiwtter in the last couple of years never lasted this long and those were attacked by the top hackers and incredibly coordinate groups.

It was explained to me that ASO doesn't know exactly which domain is being attacked on the ip/server so changing the ip for a specific domain would not solve the issue because it could bring down another server if switched... yet they don't realize this would identify the EXACT domain being hit with the attack.

It is absolutely unacceptable that there is not a backup plan or an attack shutoff contingency plan is baffling. we are approaching 12 hours straight of downtown. As ASO would agree, completely unacceptable. ASO would lost thousands of dollars an hour based on their sites being down... so do we....

Completely unprepared. Complete unacceptable.

You do not have your Wordpress files installed in your document root.  That's why this is happening.  If you are intending for your entire site to be Wordpress-based, your best option is to move the Wordpress files out of the /wp folder and into the domain's root folder so that is what people see when they type in your domain name.  That is very easy to do in cPanel as all you have to do is go into the /wp folder, select all the folders and files in the /wp folder and drag it to the left side to your domain's root folder.  As it stands now, you have two different paths in your configuration entries and that is screwing up the paths to your CSS and Javascript files so browsers are not finding them.

Otherwise, you will have to do a redirect to the /wp folder which is bad practice or do some other creative URL rewriting.  I don't think that is a good route to go if you don't have to.

OK, Price down to $200 for the forum, and again the price is negotiable. Make your offer!

This is Vbulletin 4.2.0, and also includes the Vbulletin 5 Connect!!

Hey, folks,

I first want to apologize for the elongated wait times lately, and I want to try and address some of what's said here, as there's quite a bit of information.

ASO has suffered the past few weeks with elongated wait times, and we're working extremely hard to correct it. This isn't due to staff leaving, or some kind of "corporate overlord" change - we are seeing more tickets than we used to and we were not as quick as we should have been about ramping up. Our support structure as we had it (which was all techs doing everything you can imagine whenever it was needed) began to be taxed a bit, and we're in the process of addressing those issues.

One of the things I love about working at ASO is that we course-correct pretty quickly, and we're working very hard to implement corrections to bring the response times back to what they were. It's still what we expect from ourselves, and what we know our customers expect from us. We're working very diligently to do that now, and it's clear we still have some work to do..

The folks that are here are working overtime and at a frenetic pace to ensure that everyone is taken care of while we continue to hire and train aggressively to address the support needs of our customers.

I did want to mention that we do have implemented phone support, though because we are still hiring the number is only available to current customers, and is located in your Customer Area. If you look for the button that says "Support Code" and click it, you can generate the code and get our toll free number as long as you have services with us that cost over $10/m. The phones are staffed 24/7, and we have some great folks around that can solve a variety of things by phone, or just check on a ticket you submitted if you like.

I did also want to touch on the data center migrations - the Data Center moves we did were not forced on us by anyone. These were decisions that we made and migrations that we undertook to improve our service quality, and were part of the normal course of business and planning within ASO itself.

We're continually adding staff, improving technology, and so on. I personally am making major changes to the support department to better accomodate what we're seeing and to adjust to our customers needs, and I believe that once this is completed the support responses will be back to where folks, including us, expect them to be.

Regarding the database issue - we haven't made changed that would have affected the ability to compress the database through PHPMyAdmin, but if the database has grown in size, it's possible that it's taking longer then PHPMyAdmin allows, and that's why you're having an issue - if you can let me know the ticket number, I can have someone look into it further.

If you have a major issue during this time that you feel is not being addressed adequately, please ask that the ticket be brought to my attention immediately, and I will make absolutely sure that any problems with the ticket are addressed and that your issue is resolved.

If you only open one DB connection per web request (which is all that you're likely to need) then you don't have to keep the password available for long - just do like Billzo said and store it outside the web root, then when you create the connection you include the file, use the password and never put it in a global variable. The connection can remain open and usable, but you don't need to keep the password around.

Basically, there aren't any better ways to do it other than keys. If a service runs without user intervention then either a) you have no authentication, which is obviously weaker, or b) something has to be stored as a secret that allows it access. If it is a password or a key file then it is still vulnerable to being accessed by someone else if you don't take the appropriate measures.

If you stored an encrypted password then you end up in the situation of a) accepting encrypted passwords, which takes you back to basically just having a password, b) decrypting the password, which needs another password or key (which loops round) or c) asking the user to decrypt the password, which defeats the idea of it being intervention free should it ever get restarted (which PHP in a shared hosting environment would effectively do each time).

You cannot do anything like that on a shared server.  In fact, I've never heard of storing database credentials in a server configuration file.

There is no other way but to store database user credentials in a file.  This is not just with PHP, but pretty much every language.  I don't much like it any more than you do.  I remember thinking how insecure it was years ago when I was learning to do Visual Basic programming.  Every script you can find from Wordpress to phpBB stores passwords this way.  

What I do is store the password in a file above the public_html folder.  That way there is no direct access to the file.  Your script can still include files stored above public_html.  And it is not much more secure than the traditional way, but it gives me a little more comfort.  As general rules, try to avoid storing any types of password in global variables and limit the permissions for the database to only those necessary.  If you are writing a script that does not need the ability to drop (delete) entire tables, it is best to remove that permission and other unneeded permissions in the cPanel database configuration.

SPF solves a different problem (Joe job emails). Any spammer can set up SPF records on their domain and say "any IP address can send emails from this domain" and the email is no more legitimate. I think DKIM is fairly similar - it authenticates who sent it, not the intent of what was sent.

Some blacklists are fine. I use Spamhaus and they work with ISPs to generate a list of IPs that are given out to subscribers and should never be sending email directly. I'm quite happy to block those. I'm also more than happy to blacklist the whole of China (thanks to someone who provides a handy list of Chinese IP ranges). Nothing of value to me lost there.

Blacklisting has its place, but it isn't foolproof and it has to be done well.

The only effective way I can see to stop the worst forms of spam are: a) bring in international hit-squads for the people running the rings, b) life sentences and complete bankrupting fines for anyone using the services, and c) a decade on some remote island without any Internet access for the small group of people who respond and therefore make them worthwhile sending.

I know, I know, my ideas are a bit lenient, but hey, you've got to give people at least a little bit of kindness in your tough loving.

In our continuing effort to provide our customers with the most up to date software platforms, A Small Orange would like to announce the immediate availability of PHP 5.4 on all shared servers.

Keep in mind that the use of PHP 5.4 is alongside that of the default PHP 5.3 stack, and no customers will be forced to use 5.4 unless they explicitly enable it themselves, or request it from Technical Support.

We provide you the control and option of enabling PHP 5.4 on your entire account or on a per-directory basis through a simple .htaccess modification. This modification can be placed in an accounts public_html/.htaccess file to enable PHP 5.4 for an entire account or in the .htaccess file of a specific directory to enable PHP 5.4 under that directory tree only.
To enable PHP 5.4, you must add the following htaccess option:

AddType application/x-httpd-php54 .php

The binary path to the PHP 5.4 installation, should you require it for executable php scripts or cronjobs, is located at:

/usr/local/php54/bin/php

As with the existing PHP 5.3 setup that defaults on our servers, when you enable PHP 5.4, it will respect any custom php.ini settings you may have under your account. In addition, all standard PHP modules and extensions from the existing PHP 5.3 setup are default enabled in the PHP 5.4 setup to ensure the best compatibility possible.

Please note that Zend encoded files are not supported on PHP 5.4, as Zend has yet to distribute a compatible decoder extension for PHP 5.4. However, we do include support for IonCube encoded files in PHP 5.4.

The PHP 5.4 installation will be maintained alongside our default PHP 5.3 installation on all servers going forward, to ensure that it receives version updates, bug fixes and security patches in a timely fashion.

Accounts on marrs are currently being restored. An ETA is not available for the restoration process, however further updates will be posted here as they are available.

If you didn't get an email right away, I would assume you will get one tomorrow morning when business hours start.

This migration started, and you can track nit's status here:

http://thesilence.as...nge.com/status/

Quite easy really.

1. create a new dirfectory/folder on your domain using FTP or whatever, i.e., mydomain.com/blog

2. go into your cPanel for that domain

3. scroll down to and click on Subdomains

4. on the next page, under Create a Subdomain, enter the name of that new directory, i.e., blog

5. click on the Create button and you're done.

If your domain has been sending spam email then you'll need to either a) stop it or b) tidy up after the hack that used you as a source.

More likely, though, is that you're on shared hosting and someone-else caused the server to be blacklisted. In that case then it is out of your control and ASO should be aware of it and be cleaning it up. Unfortunately, it is one of the unavoidable side-effects of shared hosting (although one that ASO do watch better than some companies).

I'd submit a ticket to Support to make sure they get their server de-listed.

slccsoccer28, on 25 October 2012 - 10:47 PM, said:

Well, it's not that it's too hard on the helpdesk, exactly - is that it becomes exceedingly difficult to find the folks that need help when a lot of people email in for questions about possible issues that, in all likelihood, they won't face. While that is one reason, it's not the only reason.

I want to reiterate again that it's not that we don't notify people, it's that we don't currently notify people by email. Our notifications are always posted in advance in the forums, which is what our initial sign up letters outline, and people have been free to craft the RSS feed to notify them in whatever way they prefer, whether it be email or reader or sms.

It seems there is a contingent of folks that would prefer that we email, and we are taking a look at creating an optional email list for technical issues for those folks that prefer not to set up an RSS feed to email them. This is one of those issues that, while folks here would prefer an email, that is not a universal preference - we try to make sure that everyone can have it "their way" and will work to get an email list up for more deeply technical alerts and server changes for those that would like them.

Hopefully, between that and the RSS feeds already in use, we should cover just about everyone.