IPTables: Blocking your favorite Brute Force Attacker

If you happen to detect a bruteforce attack on your self-hosted WP instance, this would be the IPTables syntax to block it:

iptables -A INPUT -s 119.81.130.34 -j DROP

Whenever you miss the attacker, and you’re ready to unblock, you may just type:

iptables -D INPUT -s 119.81.130.34 -j DROP

Hope this helps!

ARC: weakSelf Caveats

Here’s an interesting ARC scenario. Consider the following snippet:

[cc lang=”objc”]
__weak __typeof(self) weakSelf = self;
int64_t delay = (int64_t)(0.1 * NSEC_PER_SEC);
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, delay), dispatch_get_main_queue(), ^{
[weakSelf doSomething];
});
[/cc]

Whenever the block gets executed… weakSelf might have a valid reference, or not. Right?.
Now, what happens with the following snippet?

[cc lang=”objc”]
__weak __typeof(self) weakSelf = self;
int64_t delay = (int64_t)(0.1 * NSEC_PER_SEC);
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, delay), dispatch_get_main_queue(), ^{
[weakSelf doSomething];
[weakSelf doSomethingElse];
});
[/cc]

This is where it gets interesting!. There’s a possibility that doSomething might get executed, while doSomethingElse might not.

If you need to prevent such scenario, a possible workaround is:

[cc lang=”objc”]
__weak __typeof(self) weakSelf = self;
int64_t delay = (int64_t)(0.1 * NSEC_PER_SEC);
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, delay), dispatch_get_main_queue(), ^{
__typeof(self) strongSelf = weakSelf;
[strongSelf doSomething];
[strongSelf doSomethingElse];
});
[/cc]

This snippet warrantees that: if (at the moment of the block’s execution) weakSelf is not nil, it won’t be for the rest of the snippet.

Another interesting note (for future reference) is: self is considered strong, and it may not get invalidated at the middle of a method execution. Okay?

P.s.: Thanks to this Blog Post

Network Link Conditioner

We’ve all known, for quite some time, about the existance of the NLC tool: it’s used during iOS App Testing, under bad network conditions.

However… i’ve (recently.. cough… cough…) realized that this tool can also help you cap OS X bandwith.
This is specially useful when downloading the latest Xcode, and you don’t wanna kill the entire connection, just with that.

You can find the Network Link Conditioner in Apple’s Developers Portal, inside the Hardware IO Tools for Xcode package.

VMWare Fusion: Shrinking OSX Image

If you’re using VMWare Fusion for OSX, and you’ve got few images of older OSX releases, odds are you might have over-alloc’ed the disk space… you can never know how much it’s really gonna be required!

Steps to fix this are:

  1. Launch the OSX image that requires shrinking
  2. Open Disk Utility App
  3. Pick the Disk, click over the Partition tab, and reduce the partition’s size, as much as possible
  4. Shutdown the Virtual Machine

Once ready, you’ll need to locate the VMDK file of your image: it can be found inside the Image.vmwarevm bundle.

We’ll need to perform two final steps. Let’s fire Terminal, and head over to this location: /Applications/VMware\ Fusion.app/Contents/Library/

Once there, you may run the following commands, which will defragment the image, and free the empty space:

./vmware-vdiskmanager -d [PATH TO VMDK]
./vmware-vdiskmanager -k [PATH TO VMDK]

Hope you find it useful!

Update:
Alternative method involves installing VMWare Tools in the host machine, and running the following command:
sudo /Library/Application\ Support/VMware\ Tools/vmware-tools-cli disk shrink /