Sometimes my laptop gets to a state in which sound works through the built-in speakers, but not through the headphone jack. Possibly my solution is too brutal, but it works - restarting the whole sound subsystem. I guess that it may come handy in other situation: the ability to restart a subsystem instead of rebooting the machine, is always an advantage.
The rationale is simply reloading the kernel module that acts as a driver to our sound hardware. Reloading isn't easy, as:
My laptop's battery had just died. It made me realize how much I depend on it, for changing my working location, either when computer is awake or asleep for many hours. Without a battery, the sleep (aka suspend-to-ram) feature is less useful, for the tiniest power interruption would kill it. Continue reading →
Update: from the info I've gathered, this is most probably a problem with some Cisco IDS/DPI is running on the ethernet equipment. Workaround is available in the content below, I still don't know what's the real solution here (Cisco equipment config? update Cisco firmware?)
Starting with 5.7p1, ssh client on specific environments fails connecting to specific (usually old versioned) servers. I reproduced it on a particular network, while trying to connect using new ssh client (5.8p1, Ubuntu 11.04) to an old server (default SSH server on RedHat 5.4).
This issue is around for quite a while, but is very tricky to reproduce or understand. What bothered me most is that many people reported it to different forums, each posting only a few (different) pieces of the puzzle. So my motivation here is to try and summarize the relevant info from multiple places. I'll do my best to update this post when I hear something new.
I've already posted on configuring DHCP + Dynamic DNS for some operating systems.
I still claim that that's the only way to go for dynamic, trusted networks.
So after RedHat, Debian/Ubuntu, Windows, it's about time to stop the IP suffering with Solaris as well:
Make sure /etc/nodename contains the FQDN, e.g. "snoopy.ac.uk"
touch /etc/dhcp.<interface name> . There are two peculiar parameters I'm not fully sure about their meaning (how come they're not needed in other OSes?) - but here is what I used:
add "primary" (a separate line) if it's the primary interface.
Add "wait <seconds>" (a separate line) - I put "wait 60" to be on the safe side.
/etc/hostname.<interface name> should have the hostname inside. NOTE! It's the hostname dhcp client would send (Option 12) to the server for Dynamic DNS registration. According to /etc/defaults/dhcpagent, the format is "inet name", e.g. "inet snoopy"
That should be it, then. Please add your comments and corrections.
iSCSI is standard for accessing block devices (e.g. disks) over network, just as if they were local SCSI devices. That's similar to AoE and FCoE, although the latter two are good for the LAN only, while iSCSI is over IP thus is good on WAN. This article would focus iSCSI but could be used as a base for doing similar things with AoE and FCoE.
So, iSCSI in the simplest configuration, allows us to mount and manage a data disk that is physically connected to a remote computer (the "server", aka target) from our own computer (client, aka initiator) .
On this post I'll discuss the deep details of the more advanced stage: having the root (also boot) disk on a remote computer, so client could remotely boot from it. Surprisingly it can be done even with relatively old hardware.