OpenSuse 15.0 DHCP Problems

Just patched OpenSuse on my Lenovo C30 and DHCP appears to have stopped working.

It transpires that the DHCP server is rather old and can't deal with newer DHCP requests (it needs RFC 2132 rather than RFC 4361).

The problem is described on Bugzilla.

To save you time, all that needs to be done is to create /etc/wicked/local.xml which contains:

<config>
  <addrconf> 
    <dhcp4> 
      <create-cid>rfc2132</create-cid>
    </dhcp4>
  </addrconf>
</config>

Then restart the wicked service to pick up the new settings with:

systemctl restart wickedd

Unihertz Atom Part 2

Some further observations on the Unihertz Atom now I've had it for a bit...

1. It's a lot faster than the Jelly Pro, which sometimes felt like a compromise compared to a full sized Android phone. The Atom is as responsive as anything I've used (Samsung Galaxy's and a Sony Xperia Z5).
2. The GPS is miles better than the Jelly. In fact it seems to get a position lock faster than any of the other devices I have access too - nearly instantaneous. This I find quite remarkable considering the Jelly generally took a few minutes.
3. The battery life is excellent - even setting it up with lots of downloads and syncing it still gave me nearly 2 days of use. Overnight with Wifi and 4G on it only dropped a couple of percent. The question is: do I charge every two days to try and preserve battery life considering it's not removable?
4. On a USB PD charger it seems to charge very quickly: 30-85% in under half an hour. It does slow down after reaching around 90% but that's enough charge for a day of operation in half an hour.
5. Fingerprint reader seems to work very well for me. I would estimate that it works first time 90%+ of the time.
6. The Calender widget is not as good as the Jelly one, too much screen space wasted on a small screen. That will need replacement.
7. Even after updates the Jelly is ahead on Android patch level - consequently, I expect more updates soon. 

And now a few more config details now...

1.  Nova launcher works quite well on the Jelly, and now Atom, since it allows you ta lot of flexibility resizing widgets. In particular, it allows you remove widget padding to maximise their size, and I use full screen widgets to make the most of limited screen real estate.
2. I use a dark theme on the phone since I find white-on-black easier to read. 
3. On the first home screen I have a full screen calendar using Simple Calendar Widget which is much more space efficient (and neater) than the inbuilt widget.
4. On the second-through-fourth home screens I have full screen aquamail widgets for each of my main email accounts. These are all set to update every 15-mins and AquaMail is white-listed under Settings|Smart Assistant|Power save manager  to ensure that it is able to run in the background correctly.
5. One the fifth screen I have a full screen BBC News widget, also whitelisted like Aquamail so it updates regularly.
6. On the sixth screen have three widgets running taking up a third of the screen height but at full width: BBC Weather, Music and TuneIn Radio Pro.
7. There are no app icons on any home screens but the dock at the bottom also scroll sideways to reveal new icon sets. I have set it to hold four icons (one is always the Apps button).

This way I can get to all my key info one-handed by just side scrolling the screen with my thumb. Unlocking using a PIN is actually easier than using the fingerprint reader if the phone is held one handed since the button is so low. This is something most phone makers get wrong and I blame Apple for encouraging that design stupidity. The Xperia Z5 Compact with its fingerprint sensor on the side actually worked better for one handed operation (but only for right handers).     

Unihertz Atom Setup

Just got a Unihertz Atom phone to replace (partially) my Jelly Pro. It's quite a bit thicker but an awful lot faster. Hopefully the additional power consumption of the CPU and RAM is covered by the bigger battery. With Android 8.1 the Jelly gives me a day of good usage, which is much better than it managed with the Android 7.0 that it shipped with.

My setup on the Jelly developed over several iterations but I intend to largely replicate it on the Atom so here it is.

First of all, after letting Android update, I need to disable various bits, both to improve battery life and limit the amount of data I send to Google. In the Apps Lis,t I disable, force stop and delete the data of...

• Drive - I'm not going to be working on any documents and presentations on a screen this small!
• Duo - Cute, don't need
• Gboard - Only marginally usable on a device this small
• Gmail - Crap
• Google - If I really need it, I can fire it up in a browser, didn't miss it on the jelly
• Google Pay Movies - Are you kidding me, on that screen?
• Google Play Music - I've got my own stuff ripped
• Keep - Nope
• Maps - I want proper downloadable maps
• Pedometer
• Photos - Not really going to use this for photo viewing 
• Talkback - Not needed
• Trackback - Not needed
• Zello - I want to use the PTT button for something else

I also disable Backup (under the Google section in Settings) since I have Nextcloud for that. The PTT button is linked to the Camera App (under Smart Assistant| Shortcut button) - mainly for taking pictures of receipts for expenses.

Now the Apps that I do install:

• AquaMail - much better than Gmail, especially the widgets and multiple account handling
• BBC iPlayer - Mainly for things linked from the News App
• BBC News - again a nice widget
• BBC Weather 
• Fujifilm Camera Remote - for my X-T20
• CardDAV-Sync - My contacts sync to my NextCloud server, not Google
• DROIDCam - My GPD Pocket doesn't have a Webcam, which is generally a good thing for privacy, sometimes, however...
• FolderSync Pro - Syncs the rest of the stuff on the phone with NextCloud, mainly my music
• HERE WeGo - Downloadable maps and navigation courtesy of the ex-NavTech/Nokia guys
• Minuum - Keyboard/predictive text for small screens/fat fingers
• Nova Launcher - it's just better
• PasswdSafe - No Google/Chrome you're not doing password autofill for me either
• TuneIn Radio Pro - It's got a headphone socket!

Next, I fire up HERE WeGo and start the download of maps for all of Europe and N. America which will keep it busy while I set up email and Next Cloud sync...

   

Shoehorning Duallies - The Lenovo C30

Just picked up a Lenovo C30 from ebay, which looks like at least one company thinks like me as far as cramming a lot into a small case. In this case, a more or less EATX dual Socket 2011 motherbard in a case rather smaller than a regular PC case.

I'll be going into this into a bit more detail in a later posting but first a few observations:

1. The BIOS was rather old and Lenovo has done quite a good job at releasing regular updates to cover Intel's security holes - both in the Management Engine firmware and the whole Meltdown/Spectre debacle. However, the CDROM-based EFI BIOS update failed - judging from the error message, the EFI code on the board was too old to run the update script. So I go to use the DOS update using a Rufus generated bootable USB key - I'm running Linux on this so the Windows update was not an option. This gave me an out-of-memory error which was somewhat annoying - fortunately the error message was accompanied by the command line that flash.bat was trying to execute. Entering this manually, without the overhead of command.com and Lenovo's wrapper code, worked fine.
2. The motherboard is identical to the considerably larger Lenovo D30  but with half the RAM slots missing (8 instead of 16) to allow better airflow - the D30 has RAM cooling fans but the S30 relies on passive airflow. However, I think that a D30 motherboard would work fine with all the slots if I stick to low voltage DDR3L. If one comes up for a good price I may try that. As it is, 16GB DDR3 DIMMS are getting quite cheap on eBay and 128GB is probably enough.
3. The C30 is quiet - even with all the cores maxed out running SETI it hardly makes any sound.
4. There are several versions of the C30 and early ones, the 10xx series, don't support Ivy-Bridge Xeons but the 13xx series do. Most sellers don't distinguish and, frankly, if they're just shifting the boxes that they have, then I wouldn't expect them to know. Lenovo's documentation isn't the clearest on this either. I bought one with dual E5-2609 v2 chips to ensure that it was the right version - and then promptly swapped the CPU's for something less feeble. 
5. I'm waiting for the more beastly e5 v2 Xeons to come down a bit in price. In pairs, they hold their own against current single socket cpu's in multithreaded benchmarks rather well. I suspect that this is because multithreading tends to be memory constrained and a dual 2011 platform has 8 channels of DDR3 which isn't bettered by today's Epyc and Xeon Gold's. While they do give up a bit in bandwidth (DDR3 1866 vs DDR4 2666) the latency is almost the same - which counts for a lot as thread numbers and consequent randomness of memory accesses rise. 

Intel Quad Port PRO/1000PT and PCI-E revisited

I was really annoyed that I had to put the Intel Quad Port PRO/1000PT right next to the video card in my new build since it wouldn't work in a PCI-E 3.0 slot - and, in fact, would stop the machine from booting if inserted. That was making the video card 5-10C hotter since it was passively cooled and needed a bit of air circulation.

So I dove into the BIOS and found that I could set the PCI-E version for the PCI-E 3.0 slots (but not the 2.0 slot for some reason). This could be just the thing - so I set the problematic PCI-E slot to PCi-E 2.0 mode, remembering that Supermicro still numbers the slots as if the PCI-X slots that aren't there on the X9SRI are still there, and moved the network card over. Lo and behold! The machine booted.

Unfortunately, this was as a result of the network card just not working at all, as opposed to actively stopping the boot process. Obviously there is a subtle difference between a PCI-E 2.0 slot and a PCI-E 3.0 in 2.0 mode - remember, this is an Intel network card in a motherboard with an Intel CPU and chipset. Moderately unimpressed with both Intel and the mess that seems to be PCI-E standards.

A search for Intel documentation reveals that the low profile PT-cards are actually PCI-E 1.0a (which I wasn't aware even existed) which should work with PCI-E 2.0. Finding this was a lot harder than in the past as Intel seem to have expunged or broken links for older products. I remember when they used to have really good legacy support not so long ago (i.e. 18 months!). So I drop down to PCI-E 1.0 in the BIOS and finally everything works OK.

Outcome, a cooler, working system and increased disillusionment with Intel and the whole PCI-E mess. PCI/PCI-66/PCI-X either inter-operated or was keyed so you couldn't make a broken configuration - this is not progress, guys!  

Mobile Device Table

A summary of the portable computing devices that I have used for work over the years for no reason other than general interest. There are others (such as the Omnibook 600C) that I have owned and toyed with but not used in anger.

The heaviest device was the AST Ascentia J30 at 2650g, a large chunk of which was battery as far as I can remember. The largest screen was the Dell XPS 13 Developer Edition which, with Linux out of the box, was a real delight apart from the trackpad.

I don't get on with trackpads of any sort (yes, I've tried Macs and I find they're even more annoying than PC ones). The Omnibook popout mouse was a great idea, trackpoints are fine and touchscreen are OK provided they have stylus support. The Samsung Tab S is interesting - it has a capacitative screen but works with a special Samsung stylus with a narrow tip. I don't know how they do it since the stylus won't work on other screens.

Mfg	Model	Year	CPU	RAM	Storage	Screen Size	Screen Resolution
Casio	FX 700P	1983	Hitachi HD61913A01	2K	12K ROM	~2 inch	12 chars
HP	Omnibook 300	1993	Intel 386SXLV 16Mhz	4M	~12M ROM 10M SSD	9 inch	640x480 (16 grey levels)
AST	Ascentia J30	1996	Intel Pentium 133MHz	40M	800MB HDD	10.4 inch	800x600 DSTN (256 colours)
HP	Omnibook 800CT	1996	Intel Pentium MMX 166MHz	80M	2G HDD	10.4 inch	800x600 TFT (16 bit colour)
Fujitsu	Lifebook B2154	2000	Intel Mobile Celeron 450MHz	192M	2G HDD	10.4 inch	800x600 TFT (16 bit colour)
Sharp	Zaurus SLC1000	2005	Xscale ARM 416MHz	64M	128M SSD	3.7 inch	640x480 ICZ
Fujitsu	Lifebook U810	2007	Intel A110 800MHz	1G	60G HDD	5.6 inch	1024x600 TFT
Toshiba	NB100	2009	Intel Atom N270 1.6Ghz Hyperthreading	2G	120G HDD	8.9 inch	1024x600 TFT
Dell	XPS 13 L322X	2013	Intel Core i73537U 2GHz (3.1 turbo) Dual core+HT	8G	256GB SSD	13.3 inch	1920x1080 IPS
Samsung	Galaxy Tab S 8.4	2014	Exynos 5420 Octa	3G	32GB + 128GB MicroSDXC	8.4 Inch	2560x1600 OLED
GPD	Pocket	2017	Intel Atom X8750 1.6GHz (2.56GHz turbo) Quad core	8G	128GB SSD + 256Gb MicroSDXC	7-inch	1920x1200 IPS

Mfg	Model	Year	HxWxD (mm)	Mass (g)	Touch-screen	Track-point	Conver-tible	Notes
Casio	FX 700P	1983	71x165x10	116				BASIC Programmable Calculator
HP	Omnibook 300	1993	163x282x36	1315				MSDOS 3.3, Windows 3.1, MSOffice in ROM Popout mouse
AST	Ascentia J30	1996	289x228x47	2650		X		Win 95
HP	Omnibook 800CT	1996	185x282x40	1770				Win 95, popout mouse
Fujitsu	Lifebook B2154	2000	308x274x40	1400	X	X		Win 98
Sharp	Zaurus SLC1000	2005	128x87x24	298	X		X	Cacko Linux, Dpad
Fujitsu	Lifebook U810	2007	150x168x33	712	X	X	X	Win Vista (replaced with OpenSuse),
Toshiba	NB100	2009	225x191x33	1000				Win XP (replaced with OpenSuse)
Dell	XPS 13 L322X	2013	205x316x18	1360				Ubuntu preloaded (replaced with Kubuntu)
Samsung	Galaxy Tab S 8.4	2014	214x142x8 (inc. kbd)	647	X		X	Android, Removable Bluetooth Keyboard
GPD	Pocket	2017	180x106x18.5	480	X	X		Win 10

Old Soundblaster Live Card and Windows 10

One of my Windows 10 boxes has an old noname soundcard based on the CMedia CMI8738SX which only has Windows 7 driver. When I allowed Windows 10 to auto-upgrade the preceding Windows 7 installation, somehow it kept on working. However, at some point recently the Windows installation became borked to the point that it no longer updated - and no amount of repairing would fix it. There was nothing left but to re-install Windows from scratch (upgrade and repair installs both failed). Fortunately, everything of import is kept on my Nextcloud server so I can resync my data afterwards quite easily.

However, I could not persuade the C-Media card to work nicely with Windows 10 (it being 64-bit didn't help). I cast around and found that I had a SoundBlaster Live 5.1 PCI card sat in one of my Linux boxes, mainly because it worked with the 3.3V PCI slot in an H8DCL motherboard. However, having worked out previously that C-Media chipsets support 3.3V PCI, and can be converted merely by filing a suitable notch in the PCI connector, I duly did a swap with the Linux box (Linux supports old CMedia chipsets just fine).

The SoundBlaster is such a standard that surely Windows 10 will support it...? Nope. A visit to the Creative site confirms that there is only a W7 driver. Do I sense a conspiracy to sell new kit when the old stuff works fine? Anyway, a search online turns up the KX Project and, more importantly, their GitHub site which ensure things will hang around a bit. Under Windows 10 64-bit the driver installs fine. Ignore the bit about using KXMixer since it does not work, but the W10 mixer seems to work OK for me.

Unfortunately, they are no longer accepting donations - but a big thank you from me.

Fun and Games with the SuperMicro X9SRI

Scored a Supermicro X9SRI off eBay as a useful way of using up my DDR3 memory once I start decomissioning some of the older machines in the house. It has 8 slots so I can get a tidy 64GB into it when fully loaded. It turns out that this board - or maybe Intel's server chipsets - are a little temperamental.

I paired it with a Xeon 1650 v2 which is slightly faster than an i7-4930K and is still quite respectable CPU. That's round about a Ryzen 2600 level in modern terms and a lot cheaper, especially when you factor in the price difference between DDR3 and DDR4 RAM. And there my problems started...

I reset the BIOS, loaded up defaults and proceeded to install Linux. Everything went fine, for a while, and then I started getting random hard freezes - but not associated with any particular activity. After swapping out RAM, video cards and everything else I was till no nearer a solution. In desperation, I acquired another Xeon (E5-2609 this time - cheap enough for a quick test) and sure enough, I dropped it in and everything worked fine. So, it's the CPU, I thought, but I was puzzled by the behaviour - working fine under heavy load (Phoronix CPU Benchmark Suite) and the freezing at idle didn't seem like any other failure I'd come across. So I worked my way through the BIOS Options and discovered that the culprit was in the CPU Power Management Settings. If I set it to Power Saving (the default) then I get freezes, but if I set it to Performance then all is well. Interestingly, Linux still seems to do power saving, dropping the clockspeed and voltage of the CPU so it runs quite cool at idle. So I have no idea what the setting does other than break v2 Xeons!

I dropped an old GT 710 card in so I didn't have to live with the 1280x1024 that the on board video can do. I hesitate to call it a GPU but it's only really meant for IPMI redirection so I'm being a little unfair. That works fine with nouveau but I install the proprietary nVidia drivers which have better power management.

Finally, I drop in an Intel Quad Port PRO/1000PT to give me a few more ethernet ports to play with and the board refuses to boot - giving me beep sequences instead. A few more card swaps and it transpires that the Intel card really hates being in PCI-E 3.0 slots and will only start up in the middle, PCI-E 2.0, slot. I was hoping to put it on the slot further away from the video card since the PT gets quite warm but there you are. Reminds me of the old DOS days fiddling around with interrupt combinations to get all your peripherals to work.

Delegating ORCID Tokens

This is the final blog posting arising from the ORCID Delegation workshop held on the 10th October at Jisc in London (with representatives from Oxford, Imperial, Leeds, LSE, ORCID and Jisc). The previous blogs (Delegating ORCID Tokens – background, Revoking ORCID tokens) covered other incidental outcomes, so I will now get to the main topic – the fact that institutional ORCID users needed to explicitly grant access to third party suppliers in addition to their own institution. This behaviour has a number of undesirable side effects (repeating myself somewhat):

• Communicating this to users can be difficult since they are not always aware of these third parties
• Getting consistent takeup across multiple systems can be difficult (user loses interest) which makes downstream integration more awkward than necessary
• Institution has little visibility of these third party interactions – which can cause problems when suppliers are dropped or other issues arise
• The only way currently round this is to let a supplier use the institutional key – which however then grants them *ALL* the rights can access that the institution has

ORCID uses the OAuth(2) mechanism for authentication and authorization. OAuth already provides the functionality that will allow an institution to generate secondary tokens for third parties and subsequently revoke them:

• When an ORCID owner authorises institutional access, the institution receives two digital tokens:
  • The access token acts as a “key” that is used to access ORCID data via the ORCID API
  • The refresh token can be used to request additional tokens via the OAuth API
• There are two primary ways that the refresh token can be used:
  • To request a new access token when it nears expiry, invalidating the current access token – this has been discussed in the previous posting on revocation
  • To request an additional access token which may have reduced permissions and/or differing expiry, which leaves the current access token intact
• Multiple additional tokens can be requested
• Additional tokens can be invalidated in a similar way to regular access tokens

Obviously, this additional token mechanism is exactly what is required to allow delegated access to third parties. The issue is that there is no standard mechanism for a third party to know that they should go to an institution to get a token instead of ORCID themselves, nor is there a standard way for an institution to deliver that that token securely. There are several approaches to solving this issue:

• ORCID keeps track of additional tokens requested and who they are intended for, and issues them when requested.
  • ORCID will need API enhancements to allow institutions to indicate which tokens are for which supplier (and for a supplier to indicate which institution’s token they require)
  • These enhancements are likely to be ORCID specific rather than vanilla OAuth2 so existing code libraries will not exist
  • Institutions will need to implement and use this API, which may involve rather more information release than is desirable
  • Supplier will need to implement and use this API
  • It is unclear how a person with multiple institutional affiliations might be handled without adding significant complexity
  • Short lived tokens would require a three-way interaction between supplier, institution and ORCID – this will be complex and is unlikely to scale effectively
• Institutions provide an endpoint which the third party always contacts when it needs an access token.
  • This could be implemented as an OAuth2 proxy type of service, which could forward token requests to ORCID on behalf of the institution if an additional token does not already exist, or return an institutional token if the institution in question was not interested in delegation. If developed as a standardised packaged software appliance suitable for running on virtual or cloud infrastructures this could be deployed at an institutional level with minimal effort.
  • Institutions could automatically request and issue short lived tokens relatively easily
  • Institutions retain control over third part interactions
  • Institutions would need a secure (SSL, VPN etc.) network channel to the supplier. This is quite likely to exist already, in practice
• A third party could maintain a shared proxy-type service for use by multiple organisation
  • This would add another party that needs to be trusted into the interaction, adding effectively a second level of delegation.
  • Cost saving against a locally deployed appliance (as described above) may be minimal when the additional complexity of management is taken into account

Ideally, to make the system robust and workable, ORCID owners should have a verified institutional affiliation (or more than one if necessary) attached to their account so that a third party supplier knows who to contact for a delegation token (either directly or via ORCID). Otherwise, another mechanism would need to be found to indicate which institutions can issue tokens for a particular ORCID owners, which would be somewhat redundant. This relationship would also need to be deasserted promptly when the relationship ends. Any of these approaches will require some investment of effort by both ORCID and member institutions for development and ongoing maintenance. The key questions for the community are thus:

1. Primarily, whether there is sufficient interest and desire for a solution to the delegation problem for such an investment to be worthwhile
2. Secondarily, which route is the preferred one. On initial analysis on the day of the workshop, the feeling of the group was that an institutional proxy appliance seemed to be the most attractive option.

As a footnote, Will Simpson of ORCID noted during the meeting that using additional tokens internally for different systems within the institution was also a valid use case in that it allowed ORCID to separate requests from different sources in their logs. This greatly simplifies troubleshooting problems with interactions with multiple institutional systems.

This posting originally appeared on the UK ORCID Consortium blog.