Ubuntu dpkg Package Missing Final Newline

I’ve yet to understand why it is happening. But at least I have a temporary cure.

You get a message like the following while running apt-get upgrade:

dpkg: unrecoverable fatal error, aborting:
 files list file for package 'apache2-mpm-prefork' is missing final newline
E: Sub-process /usr/bin/dpkg returned an error code (2)

Temporary Fix

You have to move apt’s information about the package out of the way and then re-install the package. As follows:

server:root# mv /var/lib/dpkg/info/apache2-mpm-prefork.* \
  /var/lib/dpkg/info/old/

server:root# apt-get install --reinstall apache2-mpm-prefork
dpkg: warning: files list file for package 'apache2-mpm-prefork' missing; assuming package has no files currently installed

If you get warnings about other packages missing newlines repeat the procedure recursively.

Once you’ve done this you should be able to run an apt-get upgrade cleanly.

Asterisk – Setting Up A Simple Home/Office Phone Network

Goal

My goal was to set up a very simple home/office phone network with a single upstream VoIP connection that allowed dialling into the plain old telephone system (POTS) via SIP. I used Voipfone as my provider in the UK and was paying £2.40/month for an ordinary geographical phone number.

The idea was to have several extensions at home which could call each other. Each extension should be able to call the outside world by prefixing the number with the digit 9.

Incoming calls to the ordinary phone number would cause all extensions to ring – with the first one picking up to take the call.

Home PABX Design Goal

Setting Up

Linux

On an Ubuntu server I merely issued the command:

apt-get install asterisk

Configuration Files

I deleted the provided sip.conf and extensions.conf files.

Then I set up my trunk/peer (Voipfone SIP provider) along with 3 extensions numbered 201, 202, and 203.

[general]
register => username:password@sip.voipfone.net/voipfone
transport=udp

[voipfone]
type=peer
insecure=invite
dtmfmode=rfc2833
context=fromvoipfone
deny=0.0.0.0/0.0.0.0
permit=195.189.173.27/255.255.255.255
defaultuser=username
secret=password
fromdomain=myhomedomain.net
host=sip.voipfone.net

[201]
type=friend
dtmfmode=rfc2833
context=fromhomeoffice
secret=ext201
host=dynamic
mailbox=201@default

[202]
type=friend
dtmfmode=rfc2833
context=fromhomeoffice
secret=ext202
host=dynamic
mailbox=202@default

[203]
type=friend
dtmfmode=rfc2833
context=fromhomeoffice
secret=ext203
host=dynamic
mailbox=203@default

It is worth noting that the context refers to a block in the dialplan that gets called when a number originates from that extension. Clearly we want phone calls coming from the plain old telephone system (POTS) to be treated differently to calls coming from internal extensions.

The dialplan is stored in a file called extensions.conf.

;----------
; calls from the outside world ring all extensions
;----------
[fromvoipfone]
exten => voipfone,1,NoOp()
exten => voipfone,n,Dial(SIP/201&SIP/202&SIP/203)

;----------
; first check intra-office call, then outbound call
;----------
[fromhomeoffice]
include => internal
include => remote

;----------
; calling POTS by putting a 9 prefix
;----------
[remote]
exten => _9XX.,1,NoOp()
exten => _9XX.,n,Dial(SIP/voipfone/${EXTEN:1})
exten => _9XX.,n,Hangup()

;----------
; internal extensions calling internal extensions
;----------
[internal]
exten => _2XX,1,Dial(SIP/${EXTEN})

Asterisk – Getting 407 Proxy Authentication Required When Dialing Out

Using the PABX software Asterisk v1.8 on Linux I was trying to get calls from my internal network routed out via my paid-for external VoIP account.

I tried debugging by issuing the command sip set debug on but was getting messages like:

Reliably Transmitting (NAT) to 195.189.173.27:5060:
INVITE sip:155@sip.voipfone.net SIP/2.0

followed by

<--- SIP read from UDP:195.189.173.27:5060 --->
SIP/2.0 407 Proxy Authentication Required

at which point the call would fail.

What I needed in my sip.conf file in my peer definition was the following lines:

[general]
register => username:password@sip.voipfone.net/voipfone
transport=udp

[voipfone]
defaultuser=username
secret=password
type=peer
dtmfmode=rfc2833
context=fromvoipfone
deny=0.0.0.0/0.0.0.0
permit=195.189.173.27/255.255.255.255
fromuser=username
fromdomain=sip.voipfone.net
host=sip.voipfone.net

so that Asterisk could reply to this request for authentication:

Reliably Transmitting (NAT) to 195.189.173.27:5060:
INVITE sip:152@sip.voipfone.net SIP/2.0
Proxy-Authorization: Digest username='testuser', realm='asterisk', algorithm=MD5, uri='sip:152@sip.voipfone.net', nonce='42db9e63', response='ded720cda12519e7bde82e11ea21798d'

Let’s Research Batteries

Of all the charitable causes that billionaires like to donate to – perhaps an issue that does not capture their attention is a technology one: building a better battery.

Since electricity was discovered mankind has had a central problem – how to store energy. We have solved generation problems and have an abundance of free energy. But we cannot easily store large volumes of power. Instead we must use it or lose it at the instant it is created.

Power companies and national grids worldwide have created transmission networks – which usually function by scaling up the voltage of power before transmitting it as high voltage transmission requires cheaper thinner cables.

However this does not store power – the power must still be consumed as it is generated.

What problem would battery technology solve?

Imagine a world where massive amounts of power could be efficiently generated in a single desolate location – say a body of solar arrays in the Sahara Desert – or perhaps a cluster of nuclear generators far from human habitation in a stable environment (unlike, say, Japan which is subject to frequent earthquakes).

Then imagine large ships – the size of oil tankers – travelling to this offsite location – charging up – then delivering days’ worth of power for whole towns or cities.

Our best form of transportable power appears to be oil in oil tankers. The oil contains energy – then can then be refined into petrol – which can power our cars whenever we wish. Surely we can do better?

Local power needs – such as storing power generated locally by a home or village generated by intermittent sources (solar/wind) – necessitate a breakthrough in battery technology, too.

It simply does us no good to have renewable power generated for short periods only to waste it, then need that power half a day later and not have it available.

My Appeal To Billionaires

Throw money at a research institution. Put a dozen chemical engineers in there – spread out the ages. Put two or three electrical engineers in there. Then give them all kinds of materials to experiment with. Document the whole lot on a publicly readable wiki. Promise to open-source all discoveries (no patents).

When documenting – make sure every combination of materials and technique is transcribed – no matter how silly. Including “I mixed carrot juice and lemon juice into sea water but it didn’t store anything”. Let the world read and feel inspired by any discovery or failure to discover.

If we could achieve the holy grail of batteries:

• cheap materials
• safe/non-poisonous or hazardous
• can withstand high number of regular/daily cycles
• high energy storage potential
• low risk of acccidental discharge or flammability

… then we would have a much, much, MUCH stronger world as a result. Far more ecologically friendly. Much easier to supply the third world with energy. Extremely low cost of energy. Lower risk to humans of consequences of power station failure.

I believe this could be as revolutionary to the world as any other project currently being funded to support the world.

C-Style For Loop in Rust Language

A matter of some contention amongst Rust developers and users is the C-style for loop. At present it is not supported in the language – favouring iterators instead.

Simple counting jobs, such as counting from 0 to 99, are efficiently handled by the Rust compiler using the range() function.

In fact the compiler is so clever that loops over small iterated ranges can be efficiently unrolled:

fn main() {
    for i in range(0, 4u) {
        println!("{}", i)
    }
}

outputs:

0
1
2
3

… and the underlying assembler calls the print function four times rather than actually looping.

But what if you want to iterate something a little unorthodox, e.g.:

// test most specific 32-bit IPv4 netmask up to widest netmask
// in routing table
for ( mask = 4294967295; mask > 0; mask <<= 1 ) {
    ....
}

In Rust this can be expressed using the following form:

fn main() {
    for mask in std::iter::iterate(
        |x| x << 1, 
        0xFFFFFFFFu32
    ).take_while(
        |x| *x > 0
    ) {
        println!("{:t}", mask);
    }
}

Still – doesn’t roll off the tongue, does it.

It is possible to emulate a C-style for loop (contributed here) using a Rust macro:

#![feature(macro_rules)]

macro_rules! cfor {
    ($init: stmt; $cond: expr; $step: expr $body: block) => {
        {
            let mut first = true;
            $init;
            while {
                if first {
                    first = false
                } else {
                    $step
                }

                $cond
            } $body
        }
    }
}

fn main() {
    cfor!(let mut mask = 4294967295u32; mask > 0; mask <<= 1 {
        if mask & 0xFF000000u32 == 0xF0000000u32 {
            println!("{:t} (only top 4 bits set, continue)", mask);
            continue
        }
        
        if mask & 0xFF000000u32 == 0xC0000000u32 {
            println!("{:t} (only top 2 bits set, aborting)", mask);
            break;
        }

        println!("{:t}", mask);
    })
}

Which outputs:

11111111111111111111111111111111
11111111111111111111111111111110
11111111111111111111111111111100
11111111111111111111111111111000
11111111111111111111111111110000
11111111111111111111111111100000
11111111111111111111111111000000
11111111111111111111111110000000
11111111111111111111111100000000
11111111111111111111111000000000
11111111111111111111110000000000
11111111111111111111100000000000
11111111111111111111000000000000
11111111111111111110000000000000
11111111111111111100000000000000
11111111111111111000000000000000
11111111111111110000000000000000
11111111111111100000000000000000
11111111111111000000000000000000
11111111111110000000000000000000
11111111111100000000000000000000
11111111111000000000000000000000
11111111110000000000000000000000
11111111100000000000000000000000
11111111000000000000000000000000
11111110000000000000000000000000
11111100000000000000000000000000
11111000000000000000000000000000
11110000000000000000000000000000 (only top 4 bits set, continue)
11100000000000000000000000000000
11000000000000000000000000000000 (only top 2 bits set, aborting)

.. as expected.