So What About The Mac Pro?

 Computing  No Responses »
Jun 282019
 

Some of the reaction to Apple’s recent product announcements has been amusing to say the least.

First of all, let’s get the monitor out of the way first. If you think that monitor is ridiculously expensive, you’ve not looked at the specifications closely enough. Mid-range content creation monitors do cost that much – a quick look on B&H shows two monitors in the same price ballpark as the new Apple monitor, and the Apple monitor has higher specifications.

Not including the stand may seem a bit cheap, but frankly if you’ve already paid for a VESA stand that suits your working environment why pay for a stand that you will just throw away?

But yes, $1,000 for a metal stand is a little pricey. Given the negative reaction of the Apple fans at the show, I wouldn’t be surprised to see Apple drop that price (I also wouldn’t be surprised if they don’t).

Now onto the Mac Pro.

First of all, I should say that I’m not buying one – I don’t have the money, and whilst I run a somewhat underpowered workstation at work and a somewhat overpowered workstation at home, the strong points of the Mac Pro aren’t what I’m interested in and its weak points are where I’m interested in strength.

Is this expensive? Of course it is, but so is any high-end workstation – this isn’t your standard desktop PC! You can get a very roughly equivalently specced out Dell Precision 5820 for very roughly 2/3 the cost. But that comes with slower ECC memory and is much less expandable. You can also configure a Dell 7920 to a point that a Mac Pro looks cheap (it goes well above $100,000).

And you don’t buy such a system without expanding it beyond the base configuration.

This kind of machine is bought by professionals where the cost is less important than the return on investment. If it makes a professional just a little bit more productive, it can pay for itself within a year. Of the photographic (and video) professionals I watch on the tube, at least one is planning on buying three as soon as he can.

  1. Could you get a better specification ‘DIY’ machine with a budget of say $15,000? Probably although it may not be as expandable.
  2. Could you run macOS on it? Probably but it wouldn’t be supported by Apple (and that sort of thing is important in a corporate environment).
  3. Could you get next day fix or replace support for your ‘DIY’ machine? Almost certainly not; and again, when any downtime costs you money, that sort of thing is important.

There are however two criticisms I would make of Apple :-

  1. Storage. The new Mac Pro is severely limited in terms of storage expansion. In some ways that it is understandable; the sort of customer this is aimed for is likely to have a big fast NAS box somewhere. But I think they missed a trick by not offering a disk expansion chassis; perhaps an accessory tower that clips to the main tower doubling the width.
  2. No “Mac Pro Mini”. There is still an empty spot in Apple’s product line-up covering the mid-range tower territory – in fact exactly what those who criticise the Mac Pro are effectively asking for.
Cube On The Lines

Zsh: Renewed Hostname Completion

 Computing, Linux  No Responses »
Jun 082019
 

Quite a while ago, I “borrowed” some inscrutable zsh magic to automatically add the contents of ~/.ssh/known_hosts to a known_hostsi variable and used that variable to perform host name completion for certain commands. Once ssh started hashing the known_hosts file, this broke and I was busy at the time and stopped using it.

Ages later, I’ve fixed it and enhanced it a bit (and arguably made it a bit simpler). Not only does it pick up host names from the known_hosts file but also adds a list from lxc-ls and adds a few static host names (with one exception, not shown). This is done by adding the following to .zshrc :-

knownhosts=( $(sudo -b lxc-ls) )
#       Pick up a list of hosts from lxc-ls
knownhosts+="localhost"
#       Add static hostnames
for x in $(grep -v "|" ~/.ssh/known_hosts | awk '{print $1}' | awk -F, '{printf "%s ", $1}')
do
  knownhosts+=$x
done
#       Pull a list of hosts out of ~/.ssh/known_hosts excluding the Hashed hosts.
zstyle ':completion:*:(ssh|scp|sftp|ping|nmap):*' hosts $knownhosts
#       Commands to use a list of known hosts with

That probably is not the most efficient code, but does have the advantage that it is relatively easy to follow.

One addition is to add the option HashKnownHosts no to ~/.ssh/config.

There is of course a risk associated with disabling the hashing of host names within the known_hosts file. If your host becomes compromised, malicious code can use that file to obtain a list of hosts with which there is a trust relationship making it easier for an attacker to pivot through your network.

Linux Containers: Configuring Network Address (part 636)

 Computing, Linux, Working Notes  3 Responses »
Jun 052019
 

On previous occasions (yes that does mean more than once) I have messed around with the network configuration of containers to get :-

  1. A consistent behaviour.
  2. A fixed IPv4 address with no DHCP configuration (this one is easy).
  3. A fixed IPv6 address with no autoconfigured global addresses (this one has been tricky)

This turns out to be relatively easy providing that you configure the addresses within the container rather than within the container configuration. At least it looks good to go so far (I’ve been mistaken in the past).

The container configuration is quite simple :-

lxc.net.0.type = veth
lxc.net.0.flags = down
lxc.net.0.link = br0

Note that the bridge interface (br0) may be different. Also note that there is no lxc.net.0.ipv4.address, lxc.net.0.ipv4.gateway, lxc.net.0.ipv6.address, or lxc.net.0.ipv6.gateway.

The configuration within the container is dependent on what userland you are running, but for Debian (and Ubuntu if you’re not using Netplan) :-

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 10.0.0.34/16
    gateway 10.0.0.1

iface eth0 inet6 static
    address 2001:0db8:cafe:dead:0000:0000:0000:3eb/64
    scope global
    gateway 2001:0db8:cafe:dead:0000:0000:0000:0001
    privext 0
    accept_ra 0
    autoconf 0

Not sure quite which options are required but having all of “privext 0”, “accept_ra 0” and “autoconf 0” does mean no additional autoconfigured IPv6 addresses.

(And no the part number of this post isn’t anything more than a joke)

Mounting VirtualBox Disks under Linux

 Computing, Linux, Working Notes  No Responses »
Apr 102019
 

So earlier today, I had a need to mount a disk image from a virtual machine on the host, and discovered a “new” method before remembering I’d made notes on this in the past. So I’m recording the details in the probably vain hope that I’ll remember this post in the future.

The first thing to do is to add an option to include partition support in the relevant kernel module, which I’ve done by adding a line to /etc/modprobe.d/etc-modules-parameters.conf :-

options nbd max_part=63

The next step is to load the module: 

# modprobe nbd

The next is to use a Qemu tool to connect a disk image to a network block device :-

# qemu-nbd -r -c /dev/nbd0 /home/mike/lib/virtual-machine-disks/W10.vdi
# ls /dev/nbd0*
/dev/nbd0  /dev/nbd0p1  /dev/nbd0p2  /dev/nbd0p3

And next mount the relevant partition :-

# mount -o ro /dev/nbd0p2 /mnt

All done! Except for un-mounting it and finally disconnecting the network block device :-

# umount /mnt
# ls /dev/nbd0*
/dev/nbd0  /dev/nbd0p1  /dev/nbd0p2  /dev/nbd0p3
# qemu-nbd -d /dev/nbd0
/dev/nbd0 disconnected
# ls /dev/nbd0*        
/dev/nbd0

The trickiest part is the qemu-nbd command (so not very tricky at all).

The “-r” option specifies that the disk image should be connected read-only, which seems to be sensible when you’re working with a disk image that “belongs” to another machine. Obviously if you need to write to the disk image then you should drop the “-r” (but consider cloning or taking a snapshot).

The “-c” option connects the disk image to a specific device and the “-d” option disconnects the specific device.

Old Metal 2

Manually Setting IP Addresses – Use CIDR Format!

 Computing, Working Notes  No Responses »
Feb 242019
 

Normally when you set an IP address manually on an interface you do not get a whole lot of choice of how it is done – very often you have to specify the IP address itself and a network mask. The addresses and masks are almost always specified as “dotted quads” (10.0.0.1) rather than the real address in binary or decimal (167772161).

The network mask specifies what parts of the IP address are the network address and which are the host address – to determine whether a destination needs to go via a gateway or is on the local network. This is expressed as a bitmask like 255.255.255.0. Having said that, rarely some devices (Cisco routers in the dustier parts of their code) require the reverse – 0.0.0.255.

An alternative approach is to use the CIDR format to specify both the IP address of the device and the size of the network – 10.2.9.21/24. This is used (at least) on Palo Alto Networks firewalls and is probably the simplest way of configuring a network address I have come across.

Having configured hundreds of devices with static addresses … and helped solve oodles of network configuration issues, I feel that the CIDR format method is likely to be far less error prone.

If you do need to set a netmask, use ipcalc to check what it is (and use it to cut&paste rather than risk typos) :-

✓ mike@pica» ipcalc 10.2.9.21/24 
Address:   10.2.9.21            00001010.00000010.00001001. 00010101
Netmask:   255.255.255.0 = 24   11111111.11111111.11111111. 00000000
Wildcard:  0.0.0.255            00000000.00000000.00000000. 11111111
=>
Network:   10.2.9.0/24          00001010.00000010.00001001. 00000000
HostMin:   10.2.9.1             00001010.00000010.00001001. 00000001
HostMax:   10.2.9.254           00001010.00000010.00001001. 11111110
Broadcast: 10.2.9.255           00001010.00000010.00001001. 11111111
Hosts/Net: 254                   Class A, Private Internet
Through The Gateway
 Older Entries  Newer Entries