It’s often necessary to know what the exact type of CPU that’s installed on your system. For example, you may need to know if you’re dealing with a dual core or quad core system, or a 32/64 bit system. Only the CPU can tell you this.
Here’s how to find out the string you need for further investigation.
From the command line, execute the wmic command with the following parameters:
Windows also gives you an accurate result via the GUI: open Windows Explorer and head over to Computer – Properties:
Mac OS X
On the Mac you won’t get a very accurate result from the Apple Icon – About this Mac. It will tell you what CPU type you’re using, but not the exact model number.
To find that out, head over to Applications – Utilities – Terminal and enter the following command:
There. Much better than this:
You can take a look at the /proc/cpuinfo file which holds a plethora of information about your system’s CPU. So much in fact that it’s difficult to find what you’re looking for. Filtering the output of this file for ‘model name’ gives you an exact match:
Where can I find more information about my CPU?
Google is of course your friend when trying to find out more information about your processor, but there are two tools provided by Intel and AMD that may also be of help. Intel’s ARK website is particularly helpful:
I like developing and testing websites on my local network before they go live. On both Mac and PC it’s easy to tweak the /etc/hosts file so that the URL doesn’t point to a numeric IP, but instead to http://yourserver (or something equally catchy).
On iOS devices we can’t tweak that file unless we deal with the highly unethical practice of jailbreaking. Turns out there is an easier way to surf local websites on mobile devices, simply by using a Proxy Server such as Squid.
A Proxy Server is often used as a caching server or to disguise where a request is coming from. For example, surfers use proxies to pretend they’re visiting from a different country, or ISPs use proxies to speed up data delivery in local areas. In simple terms, a proxy is fetching data on our behalf. Then we talk to the proxy and get the data from him. Think of a Proxy Server as a middle man in a network transaction.
To surf local websites on an iPad or iPhone, we can connect to our WiFi network with a proxy on a machine on which we CAN tweak the /etc/hosts file. Let me show you how this works.
For this example I’m using a development server on my local network. It’s a simple LAMP Stack running CentOS.
Installing and configuring Squid
We’ll install Squid on the development server. Websites are accessible via http://localhost but also as something more swish when the /etc/hosts file is tweaked, for example http://yourserver.
Squid is available via yum, and installation is simple:
yum install squid
chkconfig squid on
The second line will start Squid on every server restart, just in case.
Squid should work out of the box on port 3128, but if you ever need to tweak this, you can do so in /etc/squid/squid.conf.
Configuring the iPad Connection
When you connect your iOS device to your local WiFi network it will do this without a Proxy Server by default. We’ll change this under Settings – WiFi, then tap the little info icon next to your active connection. It goes without saying that the development server needs to be on the same network as your iPad.
At the bottom of this page, under “http proxy”, select manual and add your development/proxy server’s numeric IP, and 3128 under Port. Leave authentication off. It should look like this:
Now any tweaked URL that works on your development server will work on the iOS Device too: visit http://yourserver to verify this.
Should Safari give you a problem, maybe due to its spurious caching technology, head over to Settings – Safari – Clear History and Website Data.
Squid will cache every request you make on your iOS device as long as your WiFi connection uses the proxy setting. Chances are that your development server isn’t going to deliver results as fast as non-cahced results would come in from your router – unless you surf the same slow website over and over.
Also, Squid will leave a record of every request that has been made in /var/log/squid/access.log. If you’re using such a setup in your office, you may need to tell users on the network that their requests will be logged.
So if you’re concerned about any of these aspects, simply switch the proxy off in your WiFi settings.
Trackbacks are a great way for other blogs to notify your blog about a link back to you. Many blogging platforms support this feature, including WordPress.
But sometimes it’s very obvious that those trackbacks aren’t coming from a legitimate source, especially when you get several dozen of them every day from the same source.
No one loves you that much.
The most recent two examples are semalt.com and buttons-for-website.com, the latter can’t even properly mix a plural with a singular. But that’s not for here.
To make sure those trackbacks don’t bother our WordPress site anymore, we can add a bit of code to your re-reite rule file. If your host is using Apache then this will be your .htaccess file, famously in use for Pretty Permalinks and some cache plugins.
A typical .htaccess file is either empty or contains a block of code courtesy of WordPress. It’s a simple text file. If we add this little snippet to the bottom of the file, friendly trackbacks from semalt.com will no longer notify our website:
# Block Semalt Trackbacks
This rather strange looking code is a rewrite rule. It says “if you encounter a link or a visitor from semalt.com, then forbid them access to anywhere on this site”.
Notice the backslash, followed by the domain extension in semalt\.com. This is necessary to escape the dot character, otherwise Apache would interpret it as an instruction. In our other example, buttons-for-website.com, we need to deal with the slashes in the domain name in the same way:
You can stack these rules in your .htaccess file and add as many as you like for your very own Trackback Spammers. Simply replace the URL in the code with your own, escaping special characters as seen above (a special character is anything that isn’t “a to z” or “0 to 9”).
Note that these rules do not prevent such websites from linking to you. However as soon as someone from the offending website clicks a link to your website, they will be denied access. On the other hand, when the same visitor would type in your URL, or come from a different website, they will be able so see your content without problems.
I was researching auto login options for CentOS today. I thought those would come in handy when GNOME is used as a standard desktop, so that the computer starts straight into the desktop environment without the need to provide a password.
It’s also a handy feature to have if the machine lives in another room and needs GNOME to login to the wireless network when I issue a remote restart.
Turns out there are two parts to the puzzle: providing auto logins and removing a pesky Keyring Dialogue that appears to come up when those are enabled. Let’s tackle both of them here.
Now when you restart your system, youruser is automatically logged in when GNOME starts.
Disabling the Keyring Dialogue
However, you may experience a Keyring Dialogue which will ask for your root password every time after a restart. This isn’t much better than the login screen. This may or may not happen, depending on your current configuration:
One article I found suggested to head over to System – Preferences – Startup Applications and simply remove the Keyring Daemon from the list. Turns out this doesn’t actually make a difference, so don’t do that (although it doesn’t seem to have an adverse effect either):
– head over to the Network Connections Icon at the top of the screen
– and right-click it
– select Edit Connections…
– pick your current wireless connection and select Edit
– provide the root password (only necessary this once)
– check the tick box Available to all users
In CentOS 7, choose the little gear icon to bring up a window. You can find the available to all users tick box in the Identity section on the left hand side.
And that’s it! On subsequent logins, GNOME will now start with youruser already logged in and your wireless network connected.
Wait! My system boots into the Command Line interface, even though I have GNOME installed. What gives?
You can tell your system in which mode to start. To do this, edit your /etc/inittab file:
I fixed a problem this morning which wouldn’t let the latest version of FileZilla v126.96.36.199 connect to one of my client’s servers anymore.
This had not been a problem in the past.
The connection itself worked, but FileZilla failed due to a problem with the TLS Certificate. Here’s the error:
Error: ReceivedTLSalert from theserver: Handshakefailed(40)
Error: Couldnot connect to server
Turns out that FileZilla have made a few changes and deprecated the insecure RC4 algorithm in FTP over TLS. Since ProFTP didn’t know the path to the server certificates, TLS failed and hence no connection was possible.
# Authenticate clients that want to use FTP over TLS?
# Allow SSL/TLS renegotiations when the client requests them, but
# do not force the renegotations. Some clients do not support
# SSL/TLS renegotiations; when mod_tls forces a renegotiation, these
# clients will close the data connection, or there will be a timeout
# on an idle data connection.
In this example the Server Certificate section contains the default path to Plesk’s certificates, but feel free to substitute them if yours are stored elsewhere.
There’s no need to restart xinetd because ProFTP creates a new process for every new connection, which will then include the new configuration. NOw FileZilla can connect without a hitch, only displaying the new Server Certificate the first time it is encountered:
Note that this issue no longer occurs with newer installations of Plesk. This particular instance of Plesk has seen many updates since version 10.4, hence the tweak was necessary.
Windows users have a great free tool called ISO2USB which efficiently transfers ISO images to a USB stick. Mac users don’t have such a luxury – at least I haven’t found one yet.
Instead we can make use of a command line tool named dd which can do this for us. It needs a few parameters though, and in this article we’ll look at what those are. The following will work in both Mavericks and Yosemite, with ISOs from CentOS 6.5 and above. Our operation will result in a bootable USB stick.
First, head over to a CentOS Mirror and download your favourite ISO image. Next, have a USB stick handy and insert it into your Mac. Now open Terminal – it’s under Applications – Utilities, or do a Spotlight search to find it.
For this example I’m assuming that the image file is called centos.iso and that it’s in your Downloads directory. Let’s enter that directory by issuing the following command:
The second command lists all files, and your ISO image should be one of them.
Find out what device your USB stick is
So far so good, we’re in the right location. The dd command needs to know which file you want to copy (see above), and the device corresponding to your USB stick. It’s easy to get confused at this point. Let me explain this:
Devices are things attached to the system, such as hard disk, memory cards and USB sticks. Each device can hold a number of partitions which is where your data is stored. Depending on how many storage devices are attached to your system, you’ll get a specific address for each device. For example, /dev/disk0 is your internal Mac hard disk in which you’ll find three partitions.
Since our ISO image will overwrite all partitions on the USB stick, we need to know what the system knows our USB stick as. Type the following to get a list of what’s attached where:
#: TYPE NAME SIZE IDENTIFIER
#: TYPE NAME SIZE IDENTIFIER
#: TYPE NAME SIZE IDENTIFIER
#: TYPE NAME SIZE IDENTIFIER
#: TYPE NAME SIZE IDENTIFIER
Looks like I’ve got 5 storage devices on my system. The one at the bottom is my USB stick, an old 4GB model currently formatted with FAT32. Your layout will be different, so keep an eye on the SIZE parameter. If your currently formatted stick is named you can identify it that way too (mine is called C64).
The device I want to use here is /dev/disk4. Note that when we get to work, everything on your USB stick will be erased when we copy the ISO over. The dd command will not warn you before this happens.
Unmount your USB stick
Before we can continue we need to make sure your USB stick isn’t mounted to OS X. If it was formatted with a filesystem that your Mac can read, then you’ll see your stick as an orange icon on the desktop. But since the dd command will do a low level format with a different filesystem, OS X needs to let go of our stick. If we don’t do this, you’ll get a “Resource busy” message in the next step.
To unmount your stick, type the following:
Unmountof all volumes on disk4 was successful
That orange icon should disappear from the desktop, and you will no longer see your USB stick in the Finder either. Leave it attached though – do not eject it.
Copy the ISO image over
Now let’s give the dd command something to do. Since we’re in the correct directory already, type the following (you will be prompted for your password):
Amend /dev/disk4 with your own device. Feel free to specify the direct path to your image file in place of centos.iso (no wildcards I’m afraid).
This step can take a long time, during which you won’t get any feedback whatsoever. That’s normal, even though it looks like your session hangs. It’s all good. As long as you leave the Terminal window open, feel free to do other things with your Mac and leave it running.
In the above example I was copying a 190MB image and it took just over four minutes. I had an abysmally slow USB stick mind you – something to keep in mind when you want to transfer a large “everything ISO” image onto a stick from 10 years ago: you’re not doing yourself a favour, it’ll take hours to copy, and just as long to boot from later.
Should you want to terminate your dd session during this time (and use a faster USB stick for example), simply hit CTRL+C and you’ll be returned to the command line.
If all went well you’ll receive a summary message at the end. Now you’re ready to boot from your stick into the wonderful world of CentOS.
Sick and tired of countless command line statements to set your firewall rules? Me too. No matter what I try, I never get the results quite right. There’s always some switch I forget and ultimately something isn’t working.
For years I was thinking, “there has to be an easier way, like there is in Plesk”?
And today I found that there is: a rather un-obvious tool called system-config-firewall. It’s a godsend and works in CentOS 6 with iptables, and in CentOS 7 with firewalld.
To make use of it, install the following two packages:
The first one is a version that runs under Gnome and KDE, and second one works on the command line.
The Command Line Version
You can invoke the command line version by running
and it will present you with the following interface. You may need to switch the firewall off temporarily, but the tool will tell you if that’s necessary:
Here’s how to use the interface:
use the cursor keys to move up and down
use the SPACE bar to select items
use TAB to choose the next option
and once selected, hit RETURN
system-config-firewall has several built-in presets, such as DNS, FTP, Mail, standard and secure http ports and many others. If you need to open a specific port, hit Add on the “other” screen and define both the port and the protocol. In this example I’m opening port 3306 for incoming MySQL traffic:
Step forward through all available options, or select Close to move back to the first screen. Make sure the Firewall Enabled option is ticked, then hit OK and all your rules will be saved.
The Desktop Version
If you have Gnome or KDE installed, you can invoke the Desktop Version from the command line like this:
In addition, there should also be a handy menu item under System – Administration – Firewall which will start the same thing.
The options are much the same, perhaps a little easier on the eye and easier to select. In addition you have a Wizard which will let you start your firewall rules with a clean slate (great if you’ve been previously poking around on the command line, potentially messing things up).
Thousand thanks to all the developers who have written this tool: Thomas Woerner, Chris Lumens, Florian Festi, Brent Fox and many others.
I ran into an interesting problem today: on a CentOS 6 server a colleague of mine wanted to reset her WordPress password via the handy link provided in the login dialogue. But rather than sending an email, WordPress got back to her with the following error message:
The e-mail could not be sent.
Possible reason: your host may have disabled the mail() function.
Intrigued I had a look at the server. To my surprise sendmail was installed, and emails could be sent from the command line as well as from PHP scripts. But not from WordPress. What was going on?
Examining the logs I came across the following error message: