Browsed by
Author: benoit

Minikube on OSX and how to access pods / services from host using their host names

Minikube on OSX and how to access pods / services from host using their host names

Lately I’ve been deployment all my services on Kubernetes. It’s really great.

When developing my code, I usually test everything on a local Kubernetes cluster. When working on Linux, I use microk8s and can access my pods and services directly using their IP address, because they share the same network.

On OSX, I’m using minikube and it’s not that straightforward. I struggled to get it working so here is how I managed to do it:

  • Install hyperkit:
git clone https://github.com/moby/hyperkit
cd hyperkit
make && sudo ln -s $(pwd)/build/hyperkit /usr/local/bin/hyperkit
  • Install minikube:
brew install minikube
  • Launch minikube and specify a custom cidr for services:
minikube start --driver=hyperkit --service-cluster-ip-range=172.17.0.0/16
  • Tell OSX to route traffic to minikube for specified cidr:
sudo route -n add 172.17.0.0/16 $(minikube ip)
  • Check minikube kube-dns IP address (usually 172.17.0.10):
kubectl --namespace=kube-system get svc
  • Tell OSX to use kube-dns as well for name resolution (you may need to turn your internet connection on and off to take it into account):
sudo echo "nameserver 172.17.0.10" > /etc/resolver/cluster.local
  • If you have a Kubernetes service running, with name “test” in default namespace and listening on port 80, you should be able to directly access it using it’s kube-dns hostname: test.default.svc.cluster.local:80
Nice little tool to view iOS/OSX provisioning profiles

Nice little tool to view iOS/OSX provisioning profiles

I stumbled upon a nice little tool today to easily see details about a provisioning profile through QuickLook in Finder:

https://github.com/chockenberry/Provisioning

Install it following the included Read Me.rtf instructions, and then go to your provisioning profiles folder: ~/Library/MobileDevice/Provisioning\ Profiles

Now, using quick look on any .mobileprovision file with a press on the space bar, you will get details about the profile, such as the expiration date, profile type, entitlements, included devices and certificates.

Fixing permission issues with Python on MacOSX

Fixing permission issues with Python on MacOSX

I have some scripts written in python on my computer. Those scripts require some external packages, such as google protobuf or pycrypto.

To install them, I used either pip or easy_install, as root. Now the problem is that some of those packages were only available when python was run as root: pretty annoying!

The solution is simple: fix the read and execute rights of the Python package directory:

sudo chmod -R ugo+rX /Library/Python/2.7/site-packages/

NB: this is for Python 2.7, you may need to adjust the path depending on which version you’re using.

Tips on symbolicating stack traces from Instruments

Tips on symbolicating stack traces from Instruments

When using instruments, especially the Allocations tool, knowing where some memory was allocated is particularly useful to fix memory leaks.

The problem is, if you’re developing an SDK (like I am), you’re analyzing a sample application (not the framework or dylib it references), and Instruments is not clever enough to load the corresponding symbols for those libs.

To fix it, after stopping the capture, right click an address in the stack trace and select “Locate dSYM…”.

You’ll be prompted with a dialog to select the dSYM folder of the corresponding library.

In case you don’t have that dSYM file available, but you know that the library you have was compiled with debug symbols, you can generate the dSYM using this command:

dsymutil <binary> -o <binary>.dSYM

 

Ignoring signals in lldb

Ignoring signals in lldb

When debugging with lldb, sometimes you can be bothered with signals being raised and stopping your application at places you don’t really care about. This is the case for instance with apps using sockets and using the SIGPIPE signal to be notified of disconnections.

By default, lldb will stop on SIGPIPE, but you can change that behaviour using this command:

(lldb) pro hand -p true -s false -n true SIGPIPE
NAME        PASS   STOP   NOTIFY
==========  =====  =====  ======
SIGPIPE     true   false  true

In our example, we want the signal to be delivered to the application because it is relying on that signal to know about the state of the socket (-p true). We don’t want to stop each time such a signal is raised though, so we use “-s false”. The last argument will change whether a message will be logged in the lldb console when the signal is raised.

Inline assembly with clang/gcc

Inline assembly with clang/gcc

So here it is, my first blog post!

What is it going to be about? (drum roll….) inline assembly!

Why would you ever need that? Because it can be handy, for performance or security reasons, to write code at the assembly level. But it can also be quite cumbersome if you want to write whole functions in separate assembly code files (.S). That’s why I’m going to give you a few useful references and examples for writing inline assembly in C or C++.

First, here is some documentation from GCC about it: https://gcc.gnu.org/onlinedocs/gcc/Using-Assembly-Language-with-C.html#Using-Assembly-Language-with-C.

I used it today on an Android project compiled with clang, so my examples will be for both ARM (EABI, 32bits) and i386 on that platform.

To illustrate the subject, our goal will be to write assembly code equivalent to the _exit(int) function. This function uses a system call behind the scene.

System calls are handled by the kernel, and work either with dedicated opcodes or with interrupts. You can find details about the different opcodes and the registers that should be used to pass the parameters and retrieve the return value here (or from man syscall).

Now, we have to know which syscall to make to exit our program. This usually depends on the platform, and you can find here a list of values for Android. For exit, that will be “1” and we can see that it takes one parameter: the exit code.

Here is how to write it in asm:

register int sys_type asm("r7") = 1;
register int res asm("r0") = 0;
register int arg asm("r0") = 0;
asm volatile ("swi 0x0\n"
                         : "=r"(res)
                         : "r"(arg), "r"(sys_type)
                         : "r0", "r7");
  • register [variable type] [variable name] asm(“[register]“) = [value] is used to assign values to a specific register
  • “=r”(res) is not really useful for the exit syscall, but for other ones, it would be where the return value is stored. “r” is to tell GCC/clang that the result is stored in a regular register, “=” means it is writable only. This first group of registers after the first colon is where we list outputs.
  • the “r”(arg), “r” (sys_type) (after the second colon) is the list of input variables. Again, “r” means it’s using regular registers.
  • the last part, after the last colon, is the list of clobbered registers, to tell GCC/clang that they may have been modified by the assembly code.

And now, the equivalent for x86:

register int sys_type asm("eax") = 1;
register int res asm("eax") = 0;
register int arg asm("ebx") = 0;
asm volatile ("int $0x80"
                          : "=a"(res)
                          : "b"(arg), "a"(sys_type)
                          : "eax", "ebx");

On x86 processors, syscall is sent using an interrupt with value 0x80, but everything else is quite similar. You can note that in both cases, the assembly is equivalent to calling exit(0) because the arg variable is set to 0.

That’s about it for today 🙂  Enjoy!