Mac OSX: shell-script to get Network configuration
If you have different "locations" configured in your network environment on mac os x, it could be useful to retrieve what environment is currently selected, to allow different behaviour (in a script for instance) depending on the location/environment.
Mac has an instruction with which you can get this informatio:
networksetup -getcurrentlocationThis command (networksetup) however has to be executed with administrative privileges. This means only a user that's allowed to administer the machine, can execute:
sudo networksetup -getcurrentlocationA non-administrative user could be interested for this information too. And since this instruction does not change the system configuration, one could think it advisable to set the set-user-ID-on-execution bit of networksetup, using
sudo chmod u+s /usr/sbin/networksetupHowever this solution would open up your networsetup for other actions. So this option seems not advisable.
One could write create a script that executes this instruction, and chmod & chown that script to execute as root:
TARGET=GetCurrentLocation.sh;
cat <<EOSCRIPT >GetCurrentLocation.sh
#!/bin/bash
networksetup -getcurrentlocation;
EOSCRIPT
chown root ${TARGET};
sudo chmod 5755 ${TARGET};
Aforementioned snippit will create a script GetCurrentLocation.sh, that does just that.
Another solution is examining /Library/Preferences/SystemConfiguration/preferences.plist
This file holds the required information.
Following script evaluates the contents of that file, and extracts what location is currently selected, without the need for any superuser stuff.
#!/bin/bash
# Filename : GetCurrentNetworkLocation.sh
# Version : $Revision: 1.1 $
# Author : Dieter Demerre
# Copyright: (c) 2010- Dieter Demerre
# Licence : (g) GPL2 (http://www.gnu.org/licenses/)
# Package : Mac Os X system scripts
# Project : Network and configuration
# History :
# 2010-01-12 ddemerre 0.1 Initial implementation
#----------------------------------------------------------------------
# Description
# script that will (try to) determine what's the current network location
#----------------------------------------------------------------------
INPUT=/Library/Preferences/SystemConfiguration/preferences.plist;
function error
{
echo ${@} >&2;
}
if [ ! -r "${INPUT}" ]; then
error "cannot read plist file ${INPUT}"
exit -1;
fi
#Get key of Currently selected Set
setInfo=$(grep -A 1 "CurrentSet" "${INPUT}");
if [ 0 -ne ${?} ]; then
error "could not retrieve CurrentSet info (${?})."
exit -2;
fi
currentSet=$(echo ${setInfo}|sed 's/[^ ]* *//;s/\/Sets\/\(.*\)<\/string>/\1/;');
#Get line number in file for (start) of definition of the selected set
notBefore=$(grep -n "<key>${currentSet}</key>" "${INPUT}"|cut -d':' -f 1);
if [ -z ${notBefore} ] || [ ${notBefore} -le 0 ]; then
error "did not find key reference ${currentSet} in input (result ${notBefore})";
exit -2;
fi
# Consider only all lines following the definition-start of the set
lines=$(wc -l "${INPUT}"|awk '{print $1;}');
tail=$(( (lines - notBefore + 1) * 1));
nameInfo=$(tail -n ${tail} "${INPUT}" | grep -A 1 '<key>UserDefinedName</key>');
# And get the string value of the UserDefinedName key.
echo ${nameInfo}|sed 's/[^ ]* *//;s/<string>\([^<]*\)<\/string>.*/\1/;';
Labels: apple, network, script
Airport Extreme, loosing WAN (adsl2 bridged) unnoticed on regular basis
in 2007, I bought an Apple Airport Extreme access point. This is connected with an ADSL modem to my ISP.
I discovered that at irregular intervals, the Internet connection would be lost, but the airport extreme would not discover this (the green led continues staring at me defiantly, even though the logging in the airport extreme would also indicate a line stating the apple ntp server could not be used to synchronize the time (whereas this synchronization is logged working fine some time before [logging states: Severity:5 Clock synchronized to network time server time.euro.apple.com (adjusted +0 seconds).]).
When I switched to ADSL2, these recurring hickups became more regular. Whenever these connection droppings occurred, a reboot (using the airport utility) of the base station (menu item "Base Station", option "Reboot") would fix the problem, after some reboot time (where the switch and airport functionality temporarily becomes unavailable (so network shares are lost, opened network files closed)) the network and the internet connection would become available again.
When replacing the airport extreme with a mac mini (and dhcp client on the mac mini activated), the internet connection (adsl2) becomes available, and is not dropped (for at least 6 days (2 test runs)).
Convinced this experience prooved the airport extreme was faulty, I contacted the apple store. There someone told me that the airport extreme must be faulty, but since the warranty period is over, the price for a repair would equal the price for a new device.
I bought myself a new time capsule, and replaced the airport extreme by it. The Internet is connected to the ADSL2 modem configured with bridging. The Time Capsule is configured to receive a DHCP response at WAN (which in fact is a fixed Internet Address). The Time Capsule also manages the local wifi with hidden ESSID and WPA2 encryption. The dhcp server in the time capsule provides configured addresses to potentially 5 LAN UTP clients, and 7 WIFI clients. Access control lists based on MAC address protects one small step further.
Although I'm happy with the increased switch speed (now 1000/100/10 instead of the 100/10MB), and the included 1TB time machine, the new machine displays the same unwanted behaviour. After about 2 to 4 hours, the Internet connection is lost without the access point discovering this loss. The access point A testrun again with the mac mini shows the mini not loosing connection (the mini however is not providing dhcp addresses to the intranet, which the extreme is).
I now run a script that at an interval tries to contact 5 websites. If all 5 consecutively fail to be contacted, an apple script is launched that will reboot the base station. These actions are logged, and show me the regularity of the failures:
20100101 165524 lost
20100101 170105 reboot
20100101 170556 OK
20100101 200953 lost [3h4m]
20100101 201533 reboot
20100101 202024 OK
20100101 220443 lost [1h45]
20100101 221009 reboot
20100101 221500 OK
20100101 234550 lost
20100101 235131 reboot
20100101 235623 OK
20100101 010000 suspended script
20100102 120000 launched script again
20100102 134558 lost
20100102 135138 erboot
20100102 135633 OK
20100102 161055 lost
20100102 161619 reboot
20100102 162107 OK
20100102 184857 lost
20010102 185437 reboot
20100102 185924 OK
This rebooting however is just a fixer,... always clears the logfile of the airport.
Labels: adsl2, airport extreme, apple, bug, hardware, network, wifi
secure synergy
now my previous post about keyboard and mouse sharing over network, is incomplete. Being a bit paranoid I do not like my keyboard-events, my clipboard and other data to be passed juste clearly over the network, so I added an ssh-layer:
- installed cygwin with openssh on the windows machine.
- put the public ssh-key of my user on laptop into authorized_keys of desktop
- on laptop:
ssh desktopuser@desktop -L24801:localhost:24800
- on laptop:
synergyc localhost:24801
Now I can use this process (setting up ssh-tunnel, and running synergyc), so the configuration (at home, with desktop being iMac) can accept laptop, and without changes to the laptop, mouse of iMac might work too.
The phase of setting up the ssh-tunnel could try to discover what environment it is in (based upon ip-address received from dhcp-server, OR based upon successfull reaching that ssh-server):
I adapted the (in my earlier post introduced
synergyc_start script into:
#!/bin/bash
while /bin/true; do
for host in worklogin@desktop-work homeuser@imac-home; do
ssh -L24801:localhost:24800 -f ${host} sleep 5;
[ ${?} = 0 ] && synergyc --no-restart --no-daemon localhost:24801;
done
done
So now that works fine, but hey, I don't want to add the root@laptop public-key to my authorized keys of my user@desktop.
I changed the script further, using a.o.
screen to run programs (in background) but allowing later access to their console.
My new
syntergyc_start has been extended to allow root-invocation, but root will execute the ssh-command as
sudo -u user:
I also added an option so the command can be executed with argument
screen to retrieve the screen on console. The screen is also used to check whether there's an existing command running already.
#!/bin/bash
# will start proxy-ssh-command in detached screen.
CLIENTNAME=laptopname;
if [ -z "${DISPLAY}" ]; then
echo "no DISPLAY variable set" >&2;
exit;
fi
if [ "$( id -n -u )" = "root" ]; then
SUDO="sudo -u laptopuser ";
screenname=root_synergy_proxy;
else
SUDO="";
screenname=user_synergy_proxy;
fi
case "$(hostname)" in
(${CLIENTNAME}|${CLIENTNAME}\.*)
proxycommand="while /bin/true; do
for host in DT1user@desktop1 DT2user@desktop2 DT3user@desktop3; do
${SUDO} ssh -L24801:localhost:24800 -f \${host} sleep 5;
[ \${?} == 0 ] && synergyc --no-restart --no-daemon localhost:24801;
done;
done;";
;;
(*)
# only allow invocation on configured machine.
echo "this script should only run on ${CLIENTNAME}.">&2;
exit;
;;
esac
#remove possible defunct screens
screen -wipe
#check for existing (running) screen
screen -list|grep -e '\<[0-9]\{1,\}\.'${screenname}'\>' >/dev/null 2>&1;
case "${?}" in
(0) # depending on existing screen, retrieve it (if requested)
[ $# -eq 1 ] && [ "$1" = "screen" ] && screen -dr ${screenname};
;;
(*) # launch the screen instruction (with screen on console if requested)
[ $# -eq 1 ] && [ "$1" = "screen" ] && resume="" || resume="-d -m";
screen ${resume} -S ${screenname} bash -c "${proxycommand}";
;;
esac;
Labels: cygwin, hardware, network, security
keyboard and mouse sharing over network
hmmm,
I'm having a laptop and a desktop, and I want both to be controllable by one set of keyboard+mouse. I discovered synergy (client existing for Microsoft Windows, linux, mac os x, ...(?)). You can find it at
sourceforge if you don't find it with your distribution.
Now I configured my laptop to be client, my desktop to be server. The server accepting connection from my laptop.
Now I can access my laptop using the keyboard & mouse of my desktop for both.
Configuration of my windows (Server):
- Start synergy (on windows machine)
- select "share this computer's keyboard and mouse"
- press "configure" (see image right).

- press the + button in the screens-section (once for all machines you wish to configure, add the server like this AND all the clients.
- in the "Links" section, configure where which display is "logically positioned", so when leaving the display (using the mouse-cursor) at one side, where should it enter (at what side).
Also provide (if needed) a "return"-link:
(DON'T THINK that if you configure to leave machine-A through your left-screen-side for the right-screen-side of machine-B, you'll automatically configure the right-side of machine-B to return to the left-side of machine-A, because you don't).
configuring the client:
- Now you don't have to configure your client, only to launch it and tell it what server to connect. [code]synergyc server[/code] (see man synergyc for extra options).
Now having it working, I set the synergy software to launch automatically
Windows:
- server to launch automatically (using the "autostart" button on the windows synergy application).
Linux (Ubuntu Feisty Fawn):
implementing suggestions on (amongst others
Ubuntu-forums, I also launch synergyc automatically).
- I created a script synergyc_start with the instructions to execute:
#!/bin/sh
synergyc servername
- and added an invocation of that script in
/etc/gdm/Init/Default, before the sysmodmap=-line.
- and added another invocation of that script in
/etc/gdm/PreSession/Default before the XSETROOT=-line.
Labels: hardware, linux, network
I have a program that checks its license with the MAC address of the (an) ethernet adapter.
Now the ethernet card was fried (last friday, lightning stroke in the neighbourhood and not only the NIC (Network Interface Card) was fried. Luckilly not the harddisk.
So now I replaced it (and the power supply), but - of course - the license would not register.
Now in Linux you can - if the driver supports it - alter your MAC address:
sudo ifconfig eth0 hw internet 00:01:02:03:04:05
where you set as eth0 the NIC reference and as
00:01:02:03:04:05 the MAC address you want your NIC to use henceforth.
Ah well, I found an nice page with an overview of how to do 'it' in different OS's (see link under title of this blog-item).
Labels: hardware, linux, network