First look: Satechi’s Type-C Power Meter

My friend John Obeto pointed out some pre-release coverage of Satechi’s new USB-C power meter a week or so ago. I’ve had a number of different USB-A (standard port) testers and meters for a while, but with more devices coming into rsts11 headquarters with Type C connections (including the XPS 13 9350 and XPS 15 9550, Apple’s 12″ Macbook, the ASUS Zenpad Z10 from Verizon, and the Nexus 6P by Huawei and Google), I’ve wanted to look at power consumption beyond what an A-to-C adapter could reveal.

For those of you new to USB-C, it’s designed (in part) to be a universal connector for power and data, incorporating high speed data in a connector shared with Thunderbolt 3 (40gbit capability), a reversible connector like Apple Lightning, and some daisy-chaining capabilities like Thunderbolt 2. The standard allows for up to 100W of power, although the highest powered adapters I’ve found are 60W. The Dell Thunderbolt 3 docking station has a non-standard option beyond this; when you’re connected to a recognized Dell device it will bump the power up to 130W just like the stock XPS 15 adapter.

But the catch is that USB-A power supplies are generally limited to 2.4A at 5V, with some exceptions for Qualcomm Quickcharge and Samsung Adaptive Fast Charging and the like (which can go to 9V or 12V on compatible devices). So most USB-A power meters will only show/handle 2.4A at 5V, or 12 watts. My smaller USB-C devices easily pull 15W whereas the XPS 15 should pull a lot more than that. Continue reading

Advertisements

How to avoid Funky Town – pet peeves on ‘sudo echo’ and pipelines #rsts11

I was reading about a Raspberry Pi supercomputer design at University of Southampton. Pretty cool stuff, but something bugged me about one of the later sections. it’s something that bites me sometimes when I’m trying to be good and use ‘sudo’ instead of ‘su’ or logging in as root.

For those of you who may not remember, ‘sudo‘ is a command that gives you some or all of the privileges of another user (often root, but not limited to that user). A sysadmin can define certain commands, options, and users that each user can “take over,” as it were. But I would guess most readers of this blog generally use ‘sudo’ to execute a command as root, or worse, to become root with ‘sudo su –

So what’s your bucket, Robert?

But anyway, Southampton’s document specifies the following command invocations to edit a system config file.

Hostname Script

If you want to rename each machine, you can do it from the Master node using:

ssh pi@192.168.1.162 ‘sudo echo “iridispi002” | sudo tee /etc/hostname’

ssh pi@192.168.1.163 ‘sudo echo “iridispi003” | sudo tee /etc/hostname’

ssh pi@192.168.1.164 ‘sudo echo “iridispi004” | sudo tee /etc/hostname’

There’s a very good reason for part of that — the ‘pi’ user cannot edit files in /etc. So what you might do as root:

ssh root@192.168.1.162 echo  iridispi002 > /etc/hostname

would fail if run as a non root account.

The eagle-eyed among you will want to write in and mention that the command above would replace /etc/hostname on the local system *after* sshing to 192.168.1.162, and you’d be right, assuming you run it as root on the local system. The way around that would be

ssh root@192.168.1.162 'echo iridispi002 > /etc/hostname'

But as a non-root user, you have to escalate your privilege to change most system config files. The suggested command:

ssh pi@192.168.1.162 'sudo echo "iridispi002" | sudo tee /etc/hostname'

is excessive for one reason.

echo‘ is not a privileged command. There is no reason to ‘sudo echo‘ — at least not that I can think of. It will not take you to Funkytown (even if you are more of a Lipps, Inc fan)

This won’t break anything, but it does execute another potentially auditable command, write another line to the sudo log file, and get you into a suboptimal habit. 

Instead,

ssh pi@192.168.1.162 'echo iridispi002 | sudo tee /etc/hostname'

would do just what we want.

Tell me about this “tee” command

tee,’ by the way, is a command that takes standard input (STDIN), writes it both to standard output (STDOUT) *and* the filename specified as a parameter. Note that tee will create a file if it doesn’t already exist, and overwrite it if it does. If you want to append to an existing file, use something like ‘tee -a <filename>‘ … for example, this will propagate your hosts file with hostnames for a popular RFC1918 subnet:

for h in $(seq 1 255);
do
      echo 192.168.1.$h host$h.mydomain host$h |\
      tee -a /etc/hosts
done

There are other ways to execute non-privileged commands and use the output to affect priviliged files. One way is to use ‘dd‘ to pass data through. For example, creating a bootable USB drive in Linux from a boot image could be done with:

dd if=ubuntugolden.img | sudo dd of=/dev/sdf1

But note that dd doesn’t protect you from yourself, so check that command before you wreck it.

So where do we go from here?

If you’re going to keep to minimal privilege escalation, which is the Right Thing(tm) to do, even if it’s inconvenient… think about what you’re using sudo for, and keep it between the navigational beacons.

And by the way, am I the only one who thinks of Robotech when I use the sixth scsi device? Probably not the best way to party like it’s 1999.

Sorta Sad Panda – End Of Support Life for Some Netscreen/SSG routers

I was just looking up some Juniper gear I saw in a local auction… and discovered that the wheels of progress are indeed rolling along.

According to the Hardware EOS Milestone page, the NetScreen 5XT and 5GT, cute little firewall/vpn boxes that seem to be all over the place, reach their end of support life on June 30th and December 31st, 2013, respectively. Considering they were announced as EOL about 5 years ago, this isn’t a big surprise.

I was a bit concerned when the same page reported that the replacement products, the SSG-5 and SSG-20, had their EOL announced in December 2011, and their “Last Date to Convert Warranty” and “Same Day Support Discontinued” date is April 29th of this year (4 weeks away). But it looks like this only applies to the Japan, Korea, and Taiwan versions. Whew.

However, some further digging… and I see ScreenOS is on its own End Of Life path… 6.1 is gone, 6.2 has through the end of 2013, and 6.3 is gone at the end of 2015.

I actually use an SSG-20 with the ADSL2+ PIM for my store’s Internet connection… and while it’s not under warranty and I don’t expect to need support, this did make me wonder what I should consider for my next CPE need.

I’d be tempted to put together an SRX240 with DOCSIS and ADSL2+, but best price I can imagine for that is $2k or so, which is more than I want to spend on this project. So maybe I’ll drive the SSG-20 into the ground, and deal with the problem when it arises. There’s always a spare ADSL2+ modem in the cabinet just in case…

Why so blue, panda bear?

I’m not all that sad, to be honest. But I have a habit of going with old technology until it no longer does what I need. Or until it’s cheaper to replace than to maintain, which can be the same thing.

Heck, I have actually installed Windows XP in the past month… and it stops getting updates any day now. And I’m used to far worse support prognoses–I’m looking at you, Cisco Linksys, with the “it’s a year old? Oh, no updates for you!” policies on a lot of your home network gear (wouldn’t be so bad if it was stuff that can run DD-WRT or OpenWRT… but RV042 and the like aren’t a fit there).

Anyway, this gear has had a good run, in the market and in my own environment. So I’ll keep an eye out for new and better gear within a minimal budget, and see where the world takes my networks.