We had a PC running Ubuntu 14.04 (with encrypted home folders), and OpenSSH. We use key-based authentication on all our servers, and so we duly copied our public SSH key into ~/.ssh/authorized_keys. However, the computer seemed to ignore this key! Whenever we tried to SSH into the PC, we would be forced to enter a password.
After a bit of troubleshooting we realised that, if an SSH session was already established and the user opened a second session, the key-based authentication worked just fine!
A workstation is running Linux Mint 17 (based on Ubuntu 14.04), and the user needs permanent access to network drives stored on a Windows Server. The drives appear on Windows workstations like so:
N: Secret Files
What we need to do is make sure that each network drive is automatically mapped and mounted on boot. Luckily for us, doing this is easy with a little help from the CIFS package and a few tweaks.
The other night I tried to RDP from Ubuntu to Windows using Remmina, only to have the connection attempt fail. The error message that popped up didn’t provide much detail and a double-check of passwords and settings indicated that those were fine.
A quick Google search revealed that the problem was being caused by my ~/.freerdp directory (or /home/user/.freerdp for those less familiar with the tilde in Linux).
Recently I’d been set the task of imaging some recently-wiped and donated laptops for one of our clients. Because I was imaging a Linux distro (or more specifically Edubuntu 14.04), I decided to set up a DRBL server (also known as Clonezilla Live), which allows you to use a computer’s network card to distribute images. The laptops were imaging fine, at least until I came upon a Dell Latitude E5510 laptop.
We’ve been working on this series for a while now (as you can gather from the series links below), and as such have covered a number of different areas:
- Rainbow Tables
- Improper practices
- Key Stretching
However, there are a couple of things we wanted to mention before we wrap everything up.
A couple of months ago I posted about DDR4 SDRAM being one of the next exciting developments in computing, and now we’re starting to see our first servers becoming available running the much faster DDR4 options. The new servers are dual-CPU (no single-CPU servers running on the new platform just yet, but they’re just around the corner).
A recent Supermicro release profiled their move from their existing Platinum DXR motherboard platform to the new Platinum DXG. Front and center in the improvements (indicated by bold lettering in the table below) is the support for up to 1TB of DDR4, which will allow for greater server performance and reliability.
When performing a Sysadmin or DevOps role, it’s inevitable that you’ll be writing up a script at some point to automate a task, such as running installers or retrieving files. One part of writing up a script, no matter how large, is that you’ll need to test it to make sure that everything is working as expected, which includes the time it takes for the script to run.
User z120pi on the Linux Mint forums had the following problem:
I have my IBM T-43 running Mint 14 networked with my Windows 8 machine and cannot transfer more than one file at a time from Win 8 to Linux. When I try to copy a group of files or a folder with more than one file from the Windows machine the first file makes it through but then the transfer stalls. The progress bar freezes and nothing further happens even if I try to abort the transfer. The second file appears to show up at the destination but it has zero size. The only way I have found to recover is to kill the process. This problem happens with both wireless and wired network connections. File size doesn’t seem to matter – a single huge file copies just fine. If use my Windows machine to copy a group of files from the Linux machine to Windows the transfer works fine as well. An suggestions?
We encountered this problem as well, when running LMDE 201403 with all updates, Cinnamon v2.0.14, and setting up a network transfer with a Windows machine. Copying the first few files from an SMB (Server Message Block, often accessed via a Samba client) drive would work fine, but then the transfer would hang in the same manner as described above.