Created by Oren Held, under the CC-BY-NC license.
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.
Complete Fact list Continue reading
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.
Update: just noticed that on a more advanced ~/.profile, I see it sourcing ~/.bashrc only if under bash (by using if [ -n "$BASH_VERSION" ]; ).
As Debian sid was just unfrozen due to Squeeze release, I recently get lots of package updates. I had the feeling that something is gonna break, even slightly, despite the relative high stability of Debian unstable.
And indeed, after 100+ updates, I could no longer login to GNOME. I'm not sure which package update caused this (bash_completion was updated to 1.3, yet the problem isn't necessarily there) . gdm nicely referred me to ~/.xsession-errors, which had something like:
sh: /etc/bash_completion.d/git: line 123: syntax error near unexpected token
<' done < <(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream) 2>/dev/null | tr '\0\n' '\n ')'
sh: /etc/bash_completion.d/git: line 123:
_grub_mkpasswd-pbkdf2': not a valid identifier_grub_script-check': not a valid identifier
I couldn't find any related Debian bug report, nor hardly anything on the internet (just some Arch Linux bugs with no clear solution).
Eventually I've found out that /etc/gdm/Xsession uses /bin/sh (a crippled shell, even though it's a symlink to /bin/bash), which indeed fails with the same error when running 'source /etc/bash_completion'. This makes sense. bash_completion[*] should be bash-compatible, and may include bash-only non-standard-shell compliant syntax.
Wondering why Xsession gets to run ~/.bash_completion indirectly, I've found that I had the following two abominations:
- 'source ~/.bashrc' command in ~/.xsession
- 'source ~/.bashrc' command in ~/.profile
I'm not sure why I had these lines, but they shouldn't be there. Bash itself and only bash should source ~/.bashrc (and it's done automatically when bash starts). It makes no sense for other shells to source it.
So the solution was simply removing these lines from ~/.profie and ~/.xsession (actually got rid of ~/.xsession completely). Still, I'm not sure which update triggered this problem.
* Actually the problem was in /etc/bash_completion/git which is a part of the 'git' package and not the 'bash-completion' package. But all the same.
Exuberant ctags is a cool, language-agnostic tool for creating tag files for your source code. Nice editors such as Vim, could use these tag files to implement the much needed 'jump to definition' feature.
Ctags is awesome, it supports Python, and is supported by Vim. It seems that the world is perfect and there's no reason to write a post about configuring it. Well... almost.
ctags has a little downside when using Python: it recognizes import lines as a definition, at least as of ctags v5.8. No need to explain why it's annoying in most cases. After 2 years of suffering, I've found it's possible to overcome this simply by adding the --python-kinds=-i option to the command line, or better: to ~/.ctags.
And just to make it complete, a quick cookbook style for setting everything up and using:
- Install ctags
e.g. aptitude install exuberant-ctags
- Configure ctags.
Add to ~/.ctags the following, one option per line:
- optional: --exclude=<partial names of bad files/directories>. e.g. --exclude=*/build/* to exclude all files inside 'build/' directories
- Add a cron to rebuild tags, for instance:
1 * * * * ctags -R -o ~/mytags ~/src
- Configure vim:
add to ~/.vimrc: :set tags=~/mytags
- Use Vim:
- vim -t <tag name> to open vim straight on the tag
- Ctrl+] to jump to tag when over a word
- Ctrl+T to pop back
- :tselect or :stselect to open
- :tnext, :tprev to go to next/prev tag finding
- :help tags for more 🙂
Update: added a new post on configuring Solaris, link below.
In today's dynamic R&D network environments, it's not easy to keep the DNS records up-to-date: hosts are reinstalled/renamed/added frequently, virtual machines are so easy to deploy and destroy, DHCP allocates different IPs..
This even leads to pitiful situations, in which people get used to referring to computer by their IPs (or using /etc/hosts), because the DNS cannot be trusted to reflect the reality.
DHCP servers have the ability to send dynamic DNS updates, as they allocate IPs to clients. The great thing, is that it even works out-of-the-box on some operating systems. Still, if it doesn't, here are 3 things to care about, so to enable this feature: Continue reading
What is this long post about?
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.
Well, it's that simple:
- Hold Ctrl+Shift+U
- Type the unicode hex code (e.g. 2603)
- Press space
Back then, Microsoft was forced (by some lawsuit) to require a mouse-click to activate each ActiveX control embedded in a web page, even Flash. This was implemented as an IE6 update, and also built-in IE7.
No need to explain why it's really annoying for users.. Ok, I'll explain anyway: think of an ActiveX control that contains buttons. Clicking the button first only activates the control, and another click is required for the button to be pressed..
Most sites used some types of hacks to overcome this.
However, there are already millions of computers with the "click-to-activate" IE version, and some of them won't install the update.. This means that I'll still have to use one of the hacks for the next few years. Annoying.