For the longest time I have been looking for a modulator that would do HD signals. I have used the standard def modulators for probably a good 25+ years and always loved making my own “cable system” in the house with various channels for different things. However with the advent of HD TV, the SD modulators were just not going to cut it for a good HD picture.
In recent years I have had a security DVR that was outputting to a SD modulator that could be viewed on any TV in the house. While it was “ok”, I always wanted the HD version of it. So one night while I was thinking of running HDMI cables from the security dvr to every TV in the house, I stumbled on VeCOAX HD Modulators from Pro Video Instruments which are $495.
Previously when I had searched for HD modulators for either ATSC or QAM the only ones that were even sort of “cheap” where from a company called ZeeVee. However, they were still a little more expensive than what I was wanting to pay with the cheapest that I saw was like around $1,200USD. So I just put up with the SD modulators until I found the VeCOAX ones.
VeCOAX has a modulator called the MiniMod-2 which will take one HDMI source and put it on any ATSC or CATV QAM channel you would like. It supports any frequency in the normal TV/CATV bands and supports ATSC to mix with OTA channels or QAM to mix with CATV channels. It also supports PSIP so you can add a 4 character label to the channel and make the channel appear as any other channel. For example, I have my modulator on CATV Channel 14, but the PSIP says it is channel 1-1.
Initially I tried to use 1080p output, but all of my TV’s (2 Samsung’s and 1 Sony) had some issues. Either the input to the modulator from the security DVR was not a clean signal or the TV’s tuners just couldn’t handle it. So there was artifacts at the top of the screen and after a few hours or more the channel would just scramble and be un-viewable until I reset the modulator.
What I ended up having to do was set the source to be 720p and then set the modulator to attenuate the signal some since it was also over-powering the tuners in the TV’s. Once I did that, the signal has been stable for a few weeks or more now.
Now the next thing to test is hooking it or another one up to a TiVO to see if it can send the TiVO signal through out the house as well. Then I may also try to do some HAM Amateur TV with it since i can set the frequency to anything.
Been doing some research lately on WiFi and security of it. So I have been doing some scans and out of the 3,655 WiFi access points I have observed, here is the breakdown on the security of them:
It is amazing that nearly a quarter of them were unencrypted. What was even more interesting I saw a bunch of them on rural roads, so it was almost like “well no one lives around me, so why encrypt it”. So I would ask that everyone, no matter where you live, please enable encryption on your Wifi. In addition don’t use WEP, please use at least WPA and preferably WPA2. If I add in WEP as being basically “un-secured” you have over 44% of the WiFi access points not being “secured”. WEP just isn’t that strong, and with people doing banking and online shopping, you shouldn’t be doing any username, password or credit card info over a open or WEP encrypted WiFi connection.
Another factoid is the preference for WiFi channel:
||2472 (13 – Non US)
It appears that Channel 6 (aka 2437 Mhz or 2.437Ghz) is the “most popular”. Probably because that is what most routers come with as a default. It also appears that a lot of people don’t change their SSID either. I saw 214 “Linksys”, 106 “NETGEAR” and 22 “belkin54g”, which are all default SSID’s. 542 total were a combination of those 3 (spelling case and maybe a number added to it).
So in the end what does this all really mean? For one vendors need to be more proactive about helping inexperienced customers to properly secure their wireless network devices. In this day and age, routers should be sold “secure by default” and really not let the router connect to the Internet until the default admin password and ssid have been changed, and proper encryption has been set up. Why do I say this? Well there are ton’s of people who just buy a WiFi router, and don’t understand that if they don’t secure it that some one in their neighborhood could use their WiFi network, with or with out permission, and do something “bad” and the next thing you know the cops will be showing up at your door because the connection was traced back to your house, NOT your neighbor’s.
Some tips for SSID’s as well.
- Please don’t make the SSID your postal address, especially if you are in an apartment don’t tack on your apartment number.
- Don’t leave it as the default from the vendor. If you do this makes it a litter easier to guess that you haven’t done any security on it, and some one can now take control over it, because you more than likely have not changed the default password.
- Don’t name it your family name, or any ones name in your family. If you do, you can fall pray to some social engineering hacks
- Make it something that is not going to interfere with some one around you if you live in a crowded area.. Nothing like having 6 WiFi’s in a small apartment building all on channel 6 all with the SSID as Linksys and different passwords on all them, you will get horrible performance.
In this day and age of computer hacks and security problems, why do companies make it awkward to change usernames and or passwords? One example of an awkward procedure to change a password is on the VMware vCenter server. If like any good security minded person you have all your passwords set to expire every 28 days or so, to change the password on the vCenter server you have to do some “command line fu” to change it. Heaven forbid that you have to change the username as well. So how do you do it? Well if you are running vCenter on a Windows 2008 server and connecting to a Oracle server (that actually holds all the data) there are a couple of things you need to do:
- Shutdown the vCenter server (disable it in the Services Control panel)
- Change the password for your vCenter user in the oracle DB
- Now here it the BIG gotcha. On the windows side you have to run a CMD prompt as an admin user. Just clicking on it in the start menu won’t do it. You have to right click on it and do “Run as Administrator”. If you fail to do this, the next step will fail and just piss you off even more. (The reason for this is the username and password are stored in the registry and I guess running cmd as normal user revokes all privs to modify the registry.)
- Now go to the location where VMware vCenter is installed and run the vpxd command with either a -p or a -P. If you use the lower case -p it will prompt you for the new database user password. If you use the -P option, right after the P you can put the new password on the command line.
- Now you should be able to start back up the vCenter processes.
Now if you need to change the userid, you need to use Regedit and go to :
HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VirtualCenter\DB (under My Computer)
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware, Inc.\VMware VirtualCenter\DB for 64 bit versions of Windows.
and change #2 to be the new userid.
This is documented in the VMware KB Article : Changing the vCenter database userid and password. But if you don’t pay attention go the run as part, you will spend a lot of time trying to figure it out even if you are logged in as an administrator.
If your password expires in Oracle while vCenter is up and running, it appears to continue to work while it is up. But if you reboot the vCenter server or restart the vCenter processes, it will “hang” and never start. They also need to make their error messages a little more detailed as to why it is ‘failing’ to start.
ZFS has been around for a while now.. I have used it for some data partitions, but when Sun added the ability to use it as the root filesystem, I was a little hesitant to start using it there. Part of it was because, I know if I get a root disk that crashes and it is on UFS, I can get in to it pretty well. ZFS was different and I was never really comfortable about using it for root, until last night. I have been looking for a way to keep a lot of Solaris machines up to date with the Recommended and Security patches and doing it with UFS seemed to be taking for ever. Part of the problem I had with keeping them updated with UFS was the shear downtime it required to install the cluster in single user mode. Multiply that by X number of machines and it is a never ending chore to update them.
This weekend I started looking at the PCA tool, since I have seen a lot of people mention good things about it. So off to my test machine and I installed a new VM with Solaris 10 10/09 ( update 8 ) in it. After the install was finished using a ZFS root, I decided to set up a PCA proxy server on another machine. The purpose of the PCA Proxy server is that it will be the one with access to the Internet to download the patches from sunsolve. It was extremely easy to do this, (in fact I have it running in a zone on my main server.)
- Created a new plain zone (can be on anything, but I wanted to keep it seperate).
- Configure the apache2 instance on the machine, by copying the /etc/apache2/httpd.conf-example to /etc/apache2/httpd.conf
- Edit the httpd.conf and change the line that says “Timeout 300” to be “Timeout 1800”. You need to make it at least 1800, if not more depending on the speed of your Internet connection. At 22Mb/s 1800 was ok for me.
- Create a directory /var/apache2/htdocs/patches, make it owned by webservd:webservd and 755 as the permissions.
- Download and save a copy of pca in /var/apache2/cgi-bin and call it pca-proxy.cgi. Make it owned by webservd:webservd and 755 as the permissions.
- Create a file in /etc called pca-proxy.conf. In it place the following:
- In order to make the proxy run a little faster on the first use, I decided to download and “cache” the latest security and recommended patch cluster. (You don’t need to do this, but if the patches are missing the pca proxy server will download them. Considering my machine needed 156 patches, this was faster…) Once the recommended and security patches were downloaded, I placed them in a temp place and unzipped the cluster. Once the cluster is unzipped, I needed to make zip files of each patch (so that the pca client can download the zip file). To do this, I went in to tmp/10_x86_Recommended/patches and ran the following:
for i in `cat patch_order`
zip -r $i $i
- Once the zipping is done, move all the patch zip files in to the /var/apache2/htdocs/patches directory.
- Start up the apache2 service “svcadm enable apache2”
- Now it is time to configure the client, copy the pca script to the client machine and place it some place, I used /root.
- Next create a config file /etc/pca.conf in it with the following:
The first two lines tells pca where to find the patches and the patchdiag.xref file. The syslog line tells it to log all activity to local7 syslog facaility. The last line “safe=1” means: Safe patch installation. Checks all files for local modifications before installing a patch. A patch will not be installed if files with local modifications would be overwritten.
- Now that the config file is created, make sure that syslog is set to handle local7 info, I have mine set to local7.info going to /var/adm/local7.log. PCA will log the patch installation stuff to that log (i.e.:
Apr 11 17:10:50 zfstest2 pca: [ID 702911 local7.notice] Installed patch 124631-36 (SunOS 5.10_x86: System Administration Applications, Network, and C)
Apr 11 19:07:04 zfstest2 pca: [ID 702911 local7.notice] Failed to install patch 118246-21 (comm_dssetup 6.4-5.05_x86: core patch) rc=15
Now comes the part that makes ZFS worth using… We are going to create a new “boot environment” and then patch that environment”
- First we need to create a new BE;
lucreate -n p20100411
The p20100411 can be anything, I used today’s date since I patched the machine today.. Makes it easy to remember when the last time the machine was patched.
- Now we need to mount it
lumount p20100411 /.alt.root
- Now we can start patching;
pca -i -R /.alt.root
- Because I cached most of the patches locally on my pca proxy, it should not take too long for it to download, unzip and install the patches in the alt root
- Once the patching is done, it will give you a summary line telling you how many patches were downloaded and installed:
Download Summary: 156 total, 156 successful, 0 skipped, 0 failed
Install Summary : 156 total, 156 successful, 0 skipped, 0 failed
- Now we need to unmount the alt root and activate it to boot:
- Now just reboot the machine. You MUST use init or shutdown, if you don’t then it won’t boot in to the new boot environment. I use
shutdown -g0 -i6 -y
- Depending on how long it takes for your machine to boot, when it comes back up it should be on the new ZFS file system:
bash-3.00# df -h
Filesystem size used avail capacity Mounted on
rpool/ROOT/p20100411 49G 6.6G 38G 15% /
- Now you can run that new patched system for how ever long it takes to verify your patches didn’t break anything. Once you are sure everything is ok, then you can delete the old install, in my case:
This should let you recover a little bit of space. In my case it was about 1.5 gig.
The only thing left is to set up a bunch of scripts to do “pca -l” about once a month to see what patches need installed and to log that. PCA has a lot of other functions than I went over here, in a couple of words, it seems to be kick ass. On top of that it is free! The ability to create new BE’s will definitely hope any one with the right amount of disk space be able to keep their system up to date.
One Tip, make sure you watch the output of the luactivate command. This is what is displayed:
The target boot environment has been activated. It will be used when you
reboot. NOTE: You MUST NOT USE the reboot, halt, or uadmin commands. You
MUST USE either the init or the shutdown command when you reboot. If you
do not use either init or shutdown, the system will not boot using the
In case of a failure while booting to the target BE, the following process
needs to be followed to fallback to the currently working boot environment:
1. Boot from Solaris failsafe or boot in single user mode from the Solaris
Install CD or Network.
2. Mount the Parent boot environment root slice to some directory (like
/mnt). You can use the following command to mount:
mount -Fzfs /dev/dsk/c1t0d0s0 /mnt
3. Run utility with out any arguments from the Parent boot
environment root slice, as shown below:
4. luactivate, activates the previous working boot environment and
indicates the result.
5. Exit Single User mode and reboot the machine.
It seems that the new “thing” on the internet these days is port scanning for port 22 (aka SSH). I was going through my firewall logs on my home router and over the last week or so, it is broken down as follows:
| United States
| Russian Federation
| Korea, Republic of
| Czech Republic
| Hong Kong
| New Zealand
| United Kingdom
| South Africa
| Moldova, Republic of
As a comparison, attempts that were blocked that weren’t ssh only totaled 1430. So are these bot’s or people looking for rogue iPhone’s or just trying to find new vulnerabilities in SSH? The interesting thing is it appears that each source IP tries 3 times. The second try is 3 seconds after the first and the third is 6 seconds after the second.
An interesting IP is 22.214.171.124, which has tried 303 times since the 14th. The IP is from Germany and also appears on several SSH dictionary attacks. So is it time to start running services on non-standard ports?