Today I have found that there is an IP in Turkey keep trying to login to my server, and I’ve found that my current settings has no protection against this brute-force login, so I did a Google search on this and would like to share with you guys.
To check if your server is currently being attacked via ssh, use this command
> tcpdump port ssh
In CentOS, the sshd config is located at /etc/ssh/sshd_config, I have uncommented the following lines:
you can also limit root access, allow only certain IP to access the ssh etc, however I’m using dynamic IP ISP and I’m used to root ssh access, so I only use these settings.
Relying only on sshd_config is not enough, the attack host still keep sending login requests and could possibly paralyse the network traffic of linux box. I need to find a way to Continue reading “Protect your server from SSH attack”
As a Linux user/administrator, It’s important to monitor the memory usage of the system and make sure the Apps are running with enough resources. To view to memory usage of your Linux box is simple, just use the command:
But do you understand all these numbers? Sounds obvious, I have total of 496MB memory, used 271MB and 225MB is free. Sometimes I see even smaller value of “free” memory, makes me wonder what actually eat up my memory. But wait….What is “buffers”, “cached” and “-/+ buffers/cache”? You’ll notice when the buffers and cached went up, the “free” will decrease. To understand what’s going on here, you need to know how Linux works.
Leaving your memory idle is not a good idea
Firstly, it’s important to know that memory or RAM is about 500x faster than a Hard drives and the access time is measured in nano-second. You definitely want your data/program ready in the memory when you need it! So that you don’t have to wait for the hard drive. What Linux do is that it will keep portion of the files you have used before (or will use soon) in the memory, to improve the performance of the OS, this is called caching. However, those memory can still be used when necessary.
Caches are also “Free” memory
From the example above, essentially I have 372MB of memory available for applications. As the memory usage of apps increase, the OS will free up the memory for the apps. Generally you don’t want to see a lot of free memory, because that means you’re wasting the resources. You want them to be used by the OS to improve overall performance, however when you notice there’s constantly very little free and cache memory, you may consider adding more memory to the system.
- free -m
- ps_mem.py (A tool to view how much memory the apps actually used)
I believed that a lot of iPhone, iPad and iPod touch owners are excited about iOS 6, which is released a while ago, and already made the upgrade. There are couple of cool new features, however, some people think it is a mess. The most obvious example is the Maps app, which the good old Google Maps is replaced with a half-baked Apple Maps. You can choose not to upgrade, but for those upgraded, you have no choice but wait for the release of Google Maps App. This is an example of the drawbacks of having closed source OS and closed App ecosystem.
A Closed ecosystem
iOS is a closed source OS, that doesn’t bother much people as long as it works. MS Windows is also closed source, but it just works. The problem of iOS is that it also comes with a tightly controlled AppStore ecosystem which distribution of Apps need to be approved by Apple. This might have proven to have a lot of advantages, users are happy because of higher quality of software, developers are happy because they can earn a living and of course Apple is happy with all that income by selling apps. However, the major problem is that developers and users cannot publish software freely on the platform and modify/customize the iOS in the way they want.
Continue reading “iOS 6 : closed source OS disaster”
You may have encountered these two concepts, when dealing with database, or generally CS problem about accessing a single resources from more than 1 processes/threads. So basically they are respectively correspond to two different assumptions.
I assume you already know what a database transaction is, it’s basically a unit of work that either completed in its entirety or have no effect. See Also ACID properties.
Let’s think optimistically!
In this assumption, we believed that the chances of conflict is small. So the validation is only performed at the end (commit time). It the thread detects the transaction fails the validation, it will simply be aborted. This reduces the time where the resource is blocked from other threads and thus improve performance in general.
But I’m Pessimistic…
This can be thought of as a “strict” assumption. You believe that the chance of conflict is high, so you always acquire the lock at the beginning of the transaction, blocking any other operations that may violate the ACID properties.
Which one should I choose in my code?
That depends. Pessimistic concurrency control is always the fail-safe approach, but it will hurts the performance. Optimistic strategy allows some performance optimization, and is the best choice generally. However, if the chances of transaction conflict is high, pessimistic strategy may provide better performance and fail-proof.
This is my notes on this topic, hope it helps your understanding. Feel free to leave your comments here!