From the manual: This must be done through the host software which takes control of the Z-Stick USB adapter while the Z-Stick is in SerialAPI-Mode.
The Danfoss ZWave PC Controller, previously available here, you can use the "Reset Controller" button to do so. Works fine in VMware Player too, so you don't need to install a bunch of stuff on your main machine.
sshfs is a neat way of mounting a file system from one machine to another over an encrypted ssh channel. However, for machine CLIENT to access a file system that resides on machine HOST, CLIENT must generally be able to log in to HOST. In addition, CLIENT must be able to connect to HOST in the first place, though a tunnel from HOST to CLIENT can easily mediate this if a connection can only be initiated in that direction.
However, the login itself may still be an issue. You might not want to type your password for HOST on CLIENT, or set up a keyless login using public/private keys. You might not entirely trust CLIENT, from which you want to access the file system.
dpipe to the rescue.
Using dpipe, available in the "vde2" package on Debian (and, likely, derivatives), you can initiate the connection the other way and use sshfs in "slave mode", in which it communicates over standard input and output instead of an SSH connection directly.
Consider this is what you'd normally do:
sshfs YOU@HOST:/mnt/remote/path /mnt/local/path
.. from CLIENT
Instead, you can do:
dpipe /usr/lib/openssh/sftp-server = ssh CLIENT sshfs :/mnt/remote/path /mnt/local/path -o slave
.. from HOST!
Add any options you want as usual, and you've got a reverse SSHFS mount.
One cautionary note: While this setup allows you to initiate the connection from HOST, keeping your login details for HOST private, it will likely still allow for clever people to access the entire file structure of HOST as the client initiating the connection, the same as could happen if you initiate the connection from CLIENT. Thus, some trust in CLIENT is still required, though perhaps considerably less trust than you'd need to do the connection as usual.
The registry on newer Windows systems has access control lists. This means that even if you run regedit.exe as an Administrator, you can still get "Access Denied" trying to erase or alter some keys (CurrentControlSet/Enum/USB comes to mind).
The solution to this is to run the registry editor as the "System" account, which can be done using psExec.
In short, the command you want is "psexec -i -d -s c:\windows\regedit.exe", and psexec is available as part of PSTools here:
Copy here, just in case: PSTools
After having to look this up a third time, I found . I made a copy here.
In short, Microsoft fucked up and you're left with the command line to do this, unless the wireless network is in range.
The following commands list all the WIFI networks you have stored, and removes the one called "Old Network":
netsh wlan show profiles netsh wlan delete profile name="Old Network"
See Vonnie's blog for more details.
It seems VMware has removed the GUI for the disk shrink feature in VMware Tools, but the good news is it's still available from the console.
The following command will shrink the disk image for drive C:
C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe disk shrink c:\
When changing your password on a samba (Linux) server, the tokens a Windows machine holds get invalidated, yet Windows does not automatically prompt for new credentials. Instead, it consistently says "access denied" when trying to access a previously available share, say, \\myfineserver\share
If you previously mapped this drive, disconnecting is trivial in explorer, but if you browsed the network to access this drive, it's not that straight forward.
There is a solution, however, which is roughly equivalent to nuking the site from orbit. Running the following commands will clear all current network credentials:
net use * /del /yes net use /persistent:no
The simplest way I've found so far:
Edit /etc/xdg/lxsession/LXDE/autostart to append:
@xset -s off
@xset s noblank
- Download Cygwin (http://www.cygwin.com/)
- Install Cygwin, selecting the autossh package.
- Start the Cygwin shell (Start -> Programs -> Cygwin).
- Generate a public/private key pair.
- At the command line, run: ssh-keygen
- Accept the default file locations
- Use an empty passphrase
- Copy your newly-created public key to the SSH server.
- scp .ssh/id_rsa.pub email@example.com:id_rsa.pub
- Add your public key to your list of authorized keys on the server.
- Login to your SSH server.
- mkdir .ssh
- cat id_rsa.pub >> .ssh/authorized_keys
- Test your key.
- Logout of your SSH sever.
- Login to your SSH server again. This time, your key will be used for authentication and you won't be challenged for your login credentials. If you are not logged in automatically, review the previous steps. Or contact your server administrator.
- Logout of your SSH server.
- Exit of the Cygwin shell.
- Install autossh as a Windows service.
- Now back in Windows, open a new command Window (Start -> Run -> cmd).
- cd C:\cygwin\bin
- cygrunsrv -I AutoSSH -p /usr/bin/autossh -a "-M 20000 -L localaddress:port:serveraddress:port firstname.lastname@example.org" -e AUTOSSH_NTSERVICE=yes
- Tweak Windows service settings.
- Open the Services management console (Administrative Tools -> Services).
- Edit the properties of the AutoSSH service.
- In the "Log On" tab, select the "This account" radio button and set the service to run as your current user.
- Start the service.
- Test your tunnels.
- Consider making a scheduled task to start the service every hour or so, in case autossh goes boom.
On this thin client I've set up, I wanted pulseaudio to run before logging in, and not have any specific users on the machine. System mode was called for.
On Wheezy, pulseaudio is by default configured for per-user sessions. To remedy this, edit /etc/default/pulseaudio, putting PULSEAUDIO_SYSTEM_START=1
Then, edit /etc/pulse/system.pa - this is the file that configures the server when system mode is used, as opposed to /etc/pulse/default.pa. At the end of said file, I added two lines and some comments:
### Enable TCP and CLI load-module module-native-protocol-tcp port=1500 auth-anonymous=1 load-module module-cli-protocol-unix
Please keep in mind that the above tcp line allows access from any host. This is a potential security problem. I restrict access using shorewall and iptables, but an alternative would be the auth-ip-acl option with a list of approved IP's. More here. Restart pulseaudio:
/etc/init.d/pulseaudio start /etc/init.d/pulseaudio restart
The above restart includes "start", because pulseaudio's default script does not start it on "restart" unless it's not already running. Stupid.
Because pulseaudio now runs as the "pulse" user, commands like pacmd are a pain to use. However, as we made sure to load module-cli-protocol-unix above, they are actually usable, you just have to run them as the "pulse" user, and point it at the correct directory.
sudo PULSE_RUNTIME_PATH=/var/run/pulse -u pulse pacmd
To get access to playing sound, you now need to run anything as "pulse"... or you can simply use the TCP socket you made. Edit /etc/pulse/client.conf and set "default-server" to "localhost:1500" or similar:
default-server = localhost:1500
Now set up SSH port forwarding for port 1500, or whichever port you used above, with something like autossh and public key logins, and you've got remote sound playing over an encrypted tunnel. Neat.
Remember to set the default-server for client computers as well.
On my Debian KVM hosts, and on the firewalls that guard them, I noticed that every two minutes, plus a couple seconds or so each time, I'd see blocked IGMP packages from 0.0.0.0 to 126.96.36.199. Googling around, I found this post, explaining that it's the multicast_snooping option for bridge-utils that's causing it. Being KVM hosts, they are indeed configured with bridges.
I added the following line to my Bash startup scripts in /etc/rc.local, and the issue is now gone:
( shopt -s nullglob; for ms in /sys/devices/virtual/net/br*/bridge/multicast_snooping; do echo -n 0 >"$ms"; done )
In short, it runs a subshell, sets the nullglob option to prevent running on a file with an asterisk in the name if no bridges were found, then puts a 0 into all found multicast_snooping configuration files. Problem solved!
Note: If you use virtual interfaces, those are in /sys/devices/virtual/net/virbr and require the same treatment.