"... an engineer who is not only competent at the analytics and technologies of engineering, but can bring value to clients, team well, design well, foster adoptions of new technologies, position for innovations, cope with accelerating change and mentor other engineers" -- CACM 2014/12
Have you ever wanted to change the kernel/distribution of a running server but you don't have access to boot media or pxe mechanisms? I had come across a solution many moons ago, but lost the link to how it could be accomplished.
The basic mechanism relies on being able to SSH into a server, remain in a console environment, build a ram based environment, unmount and rebuild the drive environment, then reboot from the modified drive environment.
Now, within the space of a week, I came across two links which describe, or at least of scripted explanations to the process:
reload.sh found on github with 192 stars (as of this writing), and links to the next one as it's source of influence
takeover.sh, also found on github but with 5808 stars (as of this writing), and has some Hacker News background -- "A script to completely take over a running Linux system remotely, allowing you to log into an in-memory rescue environment, unmount the original root filesystem, and do anything you want, all without rebooting. Replace one distro with another without touching a physical console."
I have not yet personally evaluated these scripts for my own use. But I will be sure to run the procedure in a protected, reproducible test environment prior to attempting the procedure in something resembling a production environment.
All things being equal – such as revenue, number of employees – the value of a product company that owns intellectual property (IP) is four times that of a similar service company. Generally speaking, an investor will value a service-based company at one to two times its revenue, while product-based companies are valued at four to 10 times.
GPS NTP Network Time Server (TM1000A) - The TimeMachines GPS NTP Network Time Server is a simple to use GPS based time server that supplies accurate time for all computers and time keeping devices on the network.
From the Debian bugs mailing list here is an interesting result of using non-native code in emulation:
1) Install qemu-system-arm.
2) Unpack kernel .deb, locate vmlinuz-4.9.0-8-armmp.
Or search your just-built zImage.
3) Run qemu (no root required):
qemu-system-arm -M virt -nographic -kernel vmlinuz-4.9.0-8-armmp
If you see a kernel panic - the outcome is positive, the kernel is OK.
If it just stays there eating 100% CPU - the outcome is negative.
The above is used to sus out some issues with the linux-image-4.9.0-8-armmp-lpae:armhf kernel on Banana PI and Lamobo R1, with the notes in Bug#922478. More talk of the bug on Hacker News.
The more you try to hide, the more attention you attract. -- Anon - the movie
Anonymizing one's self is difficult. Technology companies are coming up with surprising ways to bypass the cloak of 'leave me alone' we attempt to wrap around ourselves. From a news group, here is an interesting mechanism describing the continuing escalation:
The statement of purpose:
To augment what many already have said here - it's a tie between IP
address and household address and name/surname that should not be
public, the address itself is mostly harmless and it doesn't matter if
it's static or dynamic. Tracing gets done on L7 and above anyway
The statement of bypass:
In the current state of the web, if a user gets a new address, the
various web surveillance mechanisms will associate it with the previous
user identity and context after maybe a dozen web queries or two. That
gets better if the user has a strong defensive posture, blocks web
trackers, etc. But it just takes one cookie, or one login, or some other
inference, and poof, the surveillance databases know that new_address_X
is the same user as old_address_Y.
The case of the household is even worse. It takes only one cookie,
login, etc, and the surveillance databases will learn that new_prefix_P
is the same household as old_prefix_Q. Even you run Ghostery or Privacy
Badger or the latest release of Firefox, you won't escape if you share a
prefix with someone in your household who doesn't. Or with one of those
surveillance devices that masquerade as thermostats or light switches or
voice assistants.
So that's pretty bleak. If you want defense, you probably want to
allocate different /64 prefixes to different devices, and change them
really often. You may not need to change them for every devices -- no
point providing privacy to the surveillance thermostat. But for your
laptop, your tablet or your phone, they to change before the
surveillance advertisers see you access a dozen web pages or two.
-- Christian Huitema
To help the discussion of how matching identifying information can be quite easy, take the following test with your browser:
Panopticlick - is your browser safe against tracking?
To finish things off, another quote from Anon - the movie:
It is not that I have something to hide, it is that I have nothing I want you to see
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
— Brian W. Kernighan and P. J. Plauger in The Elements of Programming Style.
The Eight Fallacies of Distributed Computing -- Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences. — Peter Deutsch
Pressure Stall Information (PSI), to be upstreamed to kernel 4.20 possibly, provides for the first time a canonical way to see resource pressure increases as they develop, with new pressure metrics for three major resources—memory, CPU, and IO.
handystats - C++ library for collecting user-defined in-process runtime statistics with low overhead
There are a few web sites which have had quite a bit of work done to them to make available colour selections.
I think paletton is probably my favorite. They have a two part selector choosing a colour once choosing a variant of: a) monochromatic, b) adjacent 3 colour, c) triad 3 colour, d) tetrad 4 colour, or e) free style with 4 colour. Once chosen, you can emit the colour selection as html, css, sas, text, or a couple of other styles.
Next up is the Adobe Color CC. It has variants of analogous, monochromatic, triad, complementary, compound, shades, and custom.
I was happily building some code to filter and manage traffic in Open vSwitch via
C++ communicating via the OpenFlow interface. Then, ... well, I realized I was missing some things. In OVS's documentation, much of it uses
the command line tools to inject the rules. Some of those examples show automatic mac swaps and such. hmm, Nicera extensions but not in the openflow specification. Which means changing code to interface to other api bind points of OVS.
In stepping back and thinking about this, I came across a youtube video on youtube:
which talks about Stratum and Next-Gen SDN. I wasn't so interested in the Stratum concept in as much as I was interested in the p4.org concept of writing code to filter packets.
In Debian with Kernel "4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22)", the following are set:
# grep -i bpf /boot/config-4.19.0-1-amd64
CONFIG_CGROUP_BPF=y
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
# CONFIG_BPF_JIT_ALWAYS_ON is not set
CONFIG_IPV6_SEG6_BPF=y
CONFIG_NETFILTER_XT_MATCH_BPF=m
# CONFIG_BPFILTER is not set
CONFIG_NET_CLS_BPF=m
CONFIG_NET_ACT_BPF=m
CONFIG_BPF_JIT=y
# CONFIG_BPF_STREAM_PARSER is not set
CONFIG_LWTUNNEL_BPF=y
CONFIG_HAVE_EBPF_JIT=y
CONFIG_BPF_EVENTS=y
# CONFIG_BPF_KPROBE_OVERRIDE is not set
CONFIG_TEST_BPF=m
# grep -i xdp /boot/config-4.19.0-1-amd64
# CONFIG_XDP_SOCKETS is not set
bcc header files are in '/usr/include/bcc/'. Many tools with suffic 'bpfcc' are installed in /usr/sbin. There is a man page for each. Many many examples can be found in /usr/share/doc/bpfcc-tools/examples/doc/.
11 64bit registers, 32bit subregisters, up to 512bytes stack
Instructions 64bit wide, max 4096 per program
BPF calling convention for helpers allows for efficient mapping: a) R0 →return value from helper call, b) R1 - R5 →argument registers for helper call, c) R6 - R9 → callee saved, preserved on helper call
/proc/kallsyms exposure of JIT image as symbol for stack traces
In building an openflow controller, the controller needs to perform some packet interception, inspection, and modification activities. This is easy from a UDP perspective. But when the openflow engine forwards the complete packet, mac addresses and all, the packets need to be decoded. And for TCP, there are various connection oriented states which need to be taken in to account when trying to perform deep packet inspection.
This means creating a purpose built TCP stack to perform the state management, or someone make use of existing tools to perform the state management. In my searches, I came across:
chobits/tapip - a user-mode TCP/IP stack based on linux tap device - with a basic state machine - but I don't need the tun/tap integration as I already have the buffered inbound and outbound raw packets.
tass-belgium/picotcp - PicoTCP is a free TCP/IP stack implementation - this is better as it has an api for providing timers and packet-in/packet-out flows. Documentation looks good.
lwIP mirror - an embeddable tcp stack with a number of bundled applications.
The book "TCP/IP Illustrated, Volume 1, 2e" discusses timers extensively, something useful, as I am considering putting in the basic state handling code manually, rather than using one of the above libraries.
One way to avoid knowing or typing the specific LL address is to ping the all-nodes link scoped multicast address, and looking for the address you're after in the response.
E.g. under Linux, the following command will show all IPv6 link local addresses on the link (assuming they reply to an ICMPv6 echo request) that respond within 1 second:
# ping -w 1 -I wlp6s0 ff02::1
ping6: Warning: source address might be selected on device other than wlp6s0.
PING ff02::1(ff02::1) from :: wlp6s0: 56 data bytes
64 bytes from fe80::e54:15ff:fe66:3b9a%wlp6s0: icmp_seq=1 ttl=64 time=0.074 ms
64 bytes from fe80::aca7:4aff:fed2:a7dd%wlp6s0: icmp_seq=1 ttl=64 time=3.47 ms (DUP!)
64 bytes from fe80::400:55ff:fe40:5%wlp6s0: icmp_seq=1 ttl=64 time=3.51 ms (DUP!)
64 bytes from fe80::9e8e:cdff:fe0e:6709%wlp6s0: icmp_seq=1 ttl=64 time=216 ms (DUP!)
64 bytes from fe80::9e8e:cdff:fe0e:66ff%wlp6s0: icmp_seq=1 ttl=64 time=221 ms (DUP!)
64 bytes from fe80::fe90:d8d2:7ec5:3c8%wlp6s0: icmp_seq=1 ttl=64 time=221 ms (DUP!)
64 bytes from fe80::a65d:36ff:fe40:e31c%wlp6s0: icmp_seq=1 ttl=64 time=250 ms (DUP!)
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +6 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.074/130.707/249.971/111.633 ms
