An anonymous researcher (one person though they use “we” throughout their documentation) has released the results of an extraordinary study. By temporarily constructing a botnet on openly available devices around the world, they were able to map usage of the global internet over IPv4 at a scope and level of detail that has no rival outside of proprietary network operations databases.
Continue reading
Migrating a WordPress blog from GoDaddy to Amazon Web Services Hosting with Bitnami.
Having recently moved several sites, including this one, from GoDaddy to Amazon, I thought I’d share the process. I’m indebted to several other such blog posts whose tutorials pointed the way. (TODO: add links). I will assume, for those readers following this post, that you already know how to create an Amazon account, and that you have at least a passing familiarity with (or the ability to look up) Linux command line operations.
The first step is to spin up an Amazon EC2 instance on your account. When you choose your Amazon Machine Image (AMI), you have a huge variety of options, especially for WordPress. I recommend using the 1-click Bitnami WordPress AMI from the AWS Marketplace (TODO: add link and AMI #) – this is a free, stable release that is well-integrated into (indeed, designed specifically for) WordPress on AWS.
TODO: add screenshot
When you launch the instance, you’ll have to assign it a key pair for security. Be sure to save the private key in a safe place, because you only get one shot to download it.
TODO: add screenshot
Security Group: SSH by default. Add ports 80 (HTTP), 21 (FTP), and SFTP, and 3306 (MYSQL) access set up.
Assign an Elastic (static) IP address to the instance, so that you can access it from anywhere more easily – but be aware that if you need to shut down the instance, the IP address will release from it, and you’ll have to reassign it.
Open an SSH tunnel to the instance (user: bitnami, key: private key)
Open an FTP connection to the instance (same credentials)
TODO: add screenshot
TODO: add screenshot
export db (incld add-drop tables) from old
export content (wp exporter)
copy wp-content folder (tarball works well)
replace bitnami wp-content/ with the backup from the old one (ftp) (unzip or tar x*f on the new site)
import db via phpmyadmin (plugin)
import content via importer (plugin)
*delete ipconfig file*
if you have to change file permissions/ownership:
wp-content gets 0775, owner is bitnami, group is daemon.
backup and edit httpd.conf
– name of admin, allow override all, include wordpress.conf and virtual hosts.conf
httpd-vhosts.conf
– virtual host using name of site, point to wordpress/htdocs document root
– create a second virtual host with the temporary name of the site?
backup and edit wordpress.conf
– instead of htaccess file
sudo vi /opt/bitnami/apps/wordpress/conf/wordpress.conf
– set rewrite mod rules to /wordpress/
mysql – table wp-options
– siteurl and -home to
– 127.0.0.1/wordpress/
restart apache and mysql
fix breaks:
– front-end settings; just put the two sites side by side.
– duplicate content from importer, esp. menus
– links: esp. relational vs hard links if domain is changing (incld. directory structure e.g. example.com/blog/ into example.com/)
– images: likely bad links if wp-content and db are both imported
– plugins: this is the big one esp. if there are server config tweaks necessary. case by case basis.
dns change: a record
– point @ to AWS elastic IP
– try to keep old one as cname or subdomain a record
backup and edit wp-config.php
– to name the site
shaboom
Having recently moved several sites, including this one, from GoDaddy to Amazon, I thought I’d share the process that drove me pretty crazy at first. I’m indebted to several other such blog posts whose tutorials pointed the way:
I will assume, for those readers following this post, that you already know how to create an Amazon account, and that you have at least a passing familiarity with (or the ability to look up) Linux command line operations.
The first step is to spin up an Amazon EC2 instance on your account. When you choose your Amazon Machine Image (AMI), you have a huge variety of options, especially for WordPress. I recommend using the 1-click Bitnami WordPress AMI from the AWS Marketplace (I used ami-745af71d for Ubuntu 64-bit – a free, stable release for AWS).
When you launch the instance, you’ll have to assign it a key pair for security. Be sure to save the private key in a safe place, because you only get one shot to download it.
Security Group: SSH by default. Add ports 80 (HTTP), 21 (FTP), and SFTP, and 3306 (MYSQL) access set up.
Assign an Elastic (static) IP address to the instance, so that you can access it from anywhere more easily – but be aware that if you need to shut down the instance, the IP address will release from it, and you’ll have to reassign it. You’ll have to delete or rename bitnami’s IP configuration files (
Open an SSH tunnel to the instance (user: bitnami, key: private key)
Update and upgrade the server if necessary.
Open an FTP connection to the instance (same credentials)
On the old server:
Export your database (including an add-drop tables query) from the old host (This may be through PHPMyAdmin, for example. If you need access to the database, consider installing the WordPress plugin Portable PHPMYAdmin or Database Manager)
Export your WordPress content through the built-in Exporter Tool in WordPress. This will download a specialized XML file.
Copy your wp-content folder in its entirety from the old server via FTP or SCP.
On the new server:
If necessary, install a database management plugin like you did on the old site.
Replace the default bitnami wp-content folder with your backup from the old site via FTP or SCP.
Import your database via PHPmyadmin (or plugin)
Import your content if necessary via the Importer tool (installs like a plugin)
if you have to change file permissions/ownership:
wp-content gets 0775, owner is bitnami, group is daemon.
backup and edit httpd.conf
name of admin, allow override all, include wordpress.conf and virtual hosts.conf
httpd-vhosts.conf
virtual host using name of site, point to wordpress/htdocs document root
backup and edit wordpress.conf
instead of htaccess file
sudo vi /opt/bitnami/apps/wordpress/conf/wordpress.conf
set rewrite mod rules to /wordpress/
mysql – table wp-options
siteurl and -home to
127.0.0.1/wordpress/
restart apache and mysql
$ sudo /opt/bitnami/ctlscript.sh restart apache
$ sudo /opt/bitnami/ctlscript.sh restart mysql
fix breaks:
front-end settings; just put the two sites side by side.
duplicate content from importer, esp. menus
links: esp. relational vs hard links if domain is changing (incld. directory structure e.g. example.com/blog/ into example.com/)
images: likely bad links if wp-content and db are both imported
plugins: this is the big one esp. if there are server config tweaks necessary. case by case basis.
dns change: a record
point @ to AWS elastic IP
try to keep old one as cname or subdomain a record
backup and edit wp-config.php to name the site
shaboom
While composing the preliminary reviews of literature that surround this post (it being posted retrospectively – something pops up here about the instability of blog-time, no doubt) certain tendencies and distinctions among the many approaches to internet studies have cemented. As the time comes to distinguish my own approach and its component pieces from the existing ones, both those which contribute to it and those from which it makes more sense to distance ourselves, a synthesis of those reviews comes into form. Tracing those groups in the literature that hang together, marking the details and purposes and focus of the ongoing project, and then arguing for the validity of a fresh approach and method, this post will form a temporary holding point en route to the field statement’s proposal and procedure. But we begin just by restating the themes of the semester so far.
Continue reading
Foucault’s methodological treatise, a decade in the writing, dismantles and reassembles historiography and epistemology. Rather than treat its object — discourse — as evidence of contiguous historical phenomena, Archaeology of Knowledge (AK) situates discourse as the rules that govern our organization and understanding of historical (as well as political, social, and other sets of) knowledge. At the same time, it describes discourse as a practice that encompasses the very making of those rules. True, then, that this abbreviated forum, as always, would fall short of adequate recapitulation of the book’s themes, let alone to float critique. But we can try:
The frontiers of a book are never clear-cut: beyond the title, the first lines, and the last full stop, beyond its internal configuration and its autonomous form, it is caught up in a system of references to other books, other texts, other sentences: it is a node within a network. Continue reading
Whether coursing through archival data or meditating on turns of language, Foucault’s early works — the History of Madness, the Birth of the Clinic, the Order of Things, and the Archaeology of Knowledge — each address ways of knowing how and what we think. Based on the approach in those works, we can refocus their efforts onto a tertiary question. While lacking the familiar modulus of power, this approach can still maintain a close attention to the thought of thought as such. It helps elucidate how we conceive of the conditions to this reflexive thought, and thereby to sketch contemporary epistemic limitations. The motivating impulse here, then, is: What exists outside our conditions of possibility of thought, and how can we know it? Continue reading
