diff options
Diffstat (limited to '_posts')
| -rw-r--r-- | _posts/2014-02-01-provision-an-ec2-instance-with-vagrant-and-ansible.md | 86 | ||||
| -rw-r--r-- | _posts/2014-11-20-opening-a-file.md | 194 | ||||
| -rw-r--r-- | _posts/2015-01-31-ubuntu-on-dell-xps13.md | 19 |
3 files changed, 16 insertions, 283 deletions
diff --git a/_posts/2014-02-01-provision-an-ec2-instance-with-vagrant-and-ansible.md b/_posts/2014-02-01-provision-an-ec2-instance-with-vagrant-and-ansible.md index 6d46ff3..1fbe3fc 100644 --- a/_posts/2014-02-01-provision-an-ec2-instance-with-vagrant-and-ansible.md +++ b/_posts/2014-02-01-provision-an-ec2-instance-with-vagrant-and-ansible.md @@ -18,14 +18,7 @@ My goal with this article is to show how easy you can combine Vagrant with Ansib I have a private repository with all my rules for Ansible. But for this post, all we need is a simple playbook. So let's start by creating a directory named *vagrant*, and put inside a configuration file named *playbook.yml*, with the following content: -```yaml -- - hosts: all - sudo: yes - tasks: - - name: Install htop - apt: pkg=htop state=installed -``` +<script src="https://gist.github.com/franckcuny/fae46135ad0f3581ce6b.js"></script> What we're describing, is that for all the hosts in our inventory we will use `sudo` to install the program `htop` using `apt-get` (yes, I assume you're using a debian-based system, but you get the idea). @@ -33,94 +26,23 @@ First, we will try the setup on a local box. If you don't already have a Vagrant Now we can add the configuration file named *Vagrantfile* with this content. -```ruby -Vagrant.configure("2") do |config| - config.vm.box = "precise64" - config.vm.box_url = "http://files.vagrantup.com/precise64.box" - - config.ssh.forward_agent = true - config.vm.provision :ansible, :playbook => "playbook.yml" -end -``` +<script src="https://gist.github.com/franckcuny/aadd788101c08744a22a.js"></script> This file says that we will use the box named *precise64*, located at the given URL, and we want to provision it using Ansible, and the path to the playbook. By running `vagrant up`, a box gets started and provisioned. An inventory file is generated for us inside the directory, so ansible will know what to do. The output should be similar to this: -``` -Bringing machine 'default' up with 'virtualbox' provider... -[default] Importing base box 'precise64'... -[default] Matching MAC address for NAT networking... -[default] Setting the name of the VM... -[default] Clearing any previously set forwarded ports... -[default] Clearing any previously set network interfaces... -[default] Preparing network interfaces based on configuration... -[default] Forwarding ports... -[default] -- 22 => 2222 (adapter 1) -[default] Booting VM... -[default] Waiting for machine to boot. This may take a few minutes... -[default] Machine booted and ready! -[default] Mounting shared folders... -[default] -- /vagrant -[default] Running provisioner: ansible... - -PLAY [all] ******************************************************************** - -GATHERING FACTS *************************************************************** -The authenticity of host '[127.0.0.1]:2222 ([127.0.0.1]:2222)' can't be established. -RSA key fingerprint is 50:db:75:ba:11:2f:43:c9:ab:14:40:6d:7f:a1:ee:e3. -Are you sure you want to continue connecting (yes/no)? yes -ok: [default] - -TASK: [Install htop] ********************************************************** -changed: [default] - -PLAY RECAP ******************************************************************** -default : ok=2 changed=1 unreachable=0 failed=0 -``` +<script src="https://gist.github.com/franckcuny/e3df9a2424e4a4a12f60.js"></script> As we can see, everything went well, and the application `htop` was successfully installed. We can now run `vagrant ssh` and once logged inside the VM, run `htop`. -</section> - -<figure> -<img alt="provisioning" src="/static/imgs/vagrant-ansible-ec2.webp" Width="100%" height="100%" class='portrait' align='center'> -</figure> - -<section> - ## AWS I've created a key pair for Vagrant in the AWS console. Note the access and secret access keys, and download the SSH private key too. For this article, we will put the key into the same directory as our playbook and Vagrant's configuration. We need to install a plugin for that: `vagrant plugin install vagrant-aws`. We also need to modify our *Vagrantfile* to use a different box, and also add the configuration for AWS. -```ruby -Vagrant.configure("2") do |config| - config.vm.provision :ansible, :playbook => 'playbook.yml' - - # This configuration is for our local box, when we use virtualbox as the provider - config.vm.provider :virtualbox do |vb, override| - override.vm.box = "precise64" - override.vm.box_url = "http://files.vagrantup.com/precise64.box" - end - - # This configuration is for our EC2 instance - config.vm.provider :aws do |aws, override| - aws.access_key_id = "access key" - aws.secret_access_key = "secret access key" - # ubuntu AMI - aws.ami = "ami-e7582d8e" - aws.keypair_name = "vagrant" - aws.security_groups = ["default", "quicklaunch-1"] - - override.vm.box = "dummy" - override.vm.box_url = "https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box" - override.ssh.username = "ubuntu" - override.ssh.private_key_path = "vagrant.pem" - end -end -``` +<script src="https://gist.github.com/franckcuny/ac8cad84af5f51a923f6.js"></script> We need to override the user name to *ubuntu* and specify the path to the private key (the one we got from the AWS console when we created our new key pair) to log into the instance. The box also needs to be overridden. diff --git a/_posts/2014-11-20-opening-a-file.md b/_posts/2014-11-20-opening-a-file.md index 8637c42..0a89789 100644 --- a/_posts/2014-11-20-opening-a-file.md +++ b/_posts/2014-11-20-opening-a-file.md @@ -10,21 +10,7 @@ A very common task for a programmer is to open a file. This seems to be a trivia For this exercise, I’m going to use this very simple C program: -```c -#include <stdio.h> - -int main() { - FILE *fh; - - if ((fh = fopen("/etc/issue", "r")) == NULL) { - perror("fopen"); - return 1; - } - - fclose(fh); - return 0; -} -``` +<script src="https://gist.github.com/franckcuny/d208c34a0b8397f3e4ca.js"></script> The code does the following things: @@ -50,40 +36,7 @@ gcc -o test test.c First I want to have an overview of the execution of this program. For this we will use `strace`. -```bash -$ strace ./test -execve("./test", ["./test"], [/* 31 vars */]) = 0 -brk(0) = 0x25e0000 -access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) -mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7f97a24000 -access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) -open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 -fstat(3, {st_mode=S_IFREG|0644, st_size=33297, ...}) = 0 -mmap(NULL, 33297, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f7f97a1b000 -close(3) = 0 -access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) -open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 -read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\37\2\0\0\0\0\0"..., 832) = 832 -fstat(3, {st_mode=S_IFREG|0755, st_size=1845024, ...}) = 0 -mmap(NULL, 3953344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f7f9743e000 -mprotect(0x7f7f975f9000, 2097152, PROT_NONE) = 0 -mmap(0x7f7f977f9000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bb000) = 0x7f7f977f9000 -mmap(0x7f7f977ff000, 17088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f7f977ff000 -close(3) = 0 -mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7f97a1a000 -mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7f97a18000 -arch_prctl(ARCH_SET_FS, 0x7f7f97a18740) = 0 -mprotect(0x7f7f977f9000, 16384, PROT_READ) = 0 -mprotect(0x600000, 4096, PROT_READ) = 0 -mprotect(0x7f7f97a26000, 4096, PROT_READ) = 0 -munmap(0x7f7f97a1b000, 33297) = 0 -brk(0) = 0x25e0000 -brk(0x2601000) = 0x2601000 -open("/etc/issue", O_RDONLY) = 3 -close(3) = 0 -exit_group(0) = ? -+++ exited with 0 +++ -``` +<script src="https://gist.github.com/franckcuny/7b9b9ab4fdccab364674.js"></script> We can ignore most of that output, only the last few lines interest us. We can see two functions related to the code we wrote: @@ -96,56 +49,11 @@ The first function is the system call `open()`, and we see that it returns 3, wh Now let’s invoke the program with gdb: -```bash -$ gdb ./test -Reading symbols from ./test...done. -(gdb) break main -Breakpoint 1 at 0x4005c1 -(gdb) run -Starting program: /home/fcuny/workspace/tmp/file/test - -Breakpoint 1, 0x00000000004005c1 in main () -(gdb) disassemble -Dump of assembler code for function main: - 0x00000000004005bd <+0>: push %rbp - 0x00000000004005be <+1>: mov %rsp,%rbp -=> 0x00000000004005c1 <+4>: sub $0x10,%rsp - 0x00000000004005c5 <+8>: mov $0x400694,%esi - 0x00000000004005ca <+13>: mov $0x400696,%edi - 0x00000000004005cf <+18>: callq 0x4004b0 <fopen@plt> - 0x00000000004005d4 <+23>: mov %rax,-0x8(%rbp) - 0x00000000004005d8 <+27>: cmpq $0x0,-0x8(%rbp) - 0x00000000004005dd <+32>: jne 0x4005f0 <main+51> - 0x00000000004005df <+34>: mov $0x4006a1,%edi - 0x00000000004005e4 <+39>: callq 0x4004c0 <perror@plt> - 0x00000000004005e9 <+44>: mov $0x1,%eax - 0x00000000004005ee <+49>: jmp 0x400601 <main+68> - 0x00000000004005f0 <+51>: mov -0x8(%rbp),%rax - 0x00000000004005f4 <+55>: mov %rax,%rdi - 0x00000000004005f7 <+58>: callq 0x400480 <fclose@plt> - 0x00000000004005fc <+63>: mov $0x0,%eax - 0x0000000000400601 <+68>: leaveq - 0x0000000000400602 <+69>: retq -End of assembler dump. -``` +<script src="https://gist.github.com/franckcuny/5ab16ac3a075200aafa1.js"></script> We can see the calls (the `callq` instructions) to our three functions: `fopen()`, `perror()` and `fclose()`, but we want to take a look at what exactly is behind this functions. Let's try to dig the `fopen` instruction a little bit more (I've removed all the lines that are not the `callq` instructions): -```bash -(gdb) disassemble fopen -Dump of assembler code for function _IO_new_fopen: - 0x00007ffff7a82f65 <+5>: jmpq 0x7ffff7a82eb0 <__fopen_internal> -End of assembler dump. -(gdb) disassemble __fopen_internal -Dump of assembler code for function __fopen_internal: - 0x00007ffff7a82ec8 <+24>: callq 0x7ffff7a33410 <memalign@plt> - 0x00007ffff7a82ef8 <+72>: callq 0x7ffff7a90760 <_IO_no_init> - 0x00007ffff7a82f0e <+94>: callq 0x7ffff7a8e640 <_IO_new_file_init> - 0x00007ffff7a82f1f <+111>: callq 0x7ffff7a8e920 <_IO_new_file_fopen> - 0x00007ffff7a82f40 <+144>: callq 0x7ffff7a8f510 <__GI__IO_un_link> - 0x00007ffff7a82f48 <+152>: callq 0x7ffff7a33470 <free@plt+48> -End of assembler dump. -``` +<script src="https://gist.github.com/franckcuny/1d7883696306611e9bd3.js"></script> OK, so here we can see that we’re calling the function `_IO_new_file_fopen()`. @@ -175,49 +83,13 @@ To open a file, you need to locate it on the disk. A file is associated with an You can run `man 1 stat` in your shell on the file to see the information we can find. -```bash -$ stat /etc/issue - File: ‘/etc/issue’ - Size: 26 Blocks: 8 IO Block: 4096 regular file -Device: fd01h/64769d Inode: 679618 Links: 1 -Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) -Access: 2014-11-16 20:04:27.655399999 -0800 -Modify: 2014-07-22 08:33:52.000000000 -0700 -Change: 2014-07-25 08:02:10.698239112 -0700 - Birth: - -``` +<script src="https://gist.github.com/franckcuny/0104bdea0e515f809ad4.js"></script> An inode is a data structure to represent an object on the filesystem. If you look at the previous output, you can see information like the size, the number of blocks, how many references exists to this file (links), etc. Here, we can see that the inode is 679618. Now let’s take a look with the FS debugger: -```bash -$ sudo debugfs /dev/vda1 -debugfs 1.42.9 (4-Feb-2014) - -debugfs: ncheck 679618 # check that the path is correct for that inode -Inode Pathname -679618 /etc/issue - -debugfs: stat <679618> # display information for that inode -Inode: 679618 Type: regular Mode: 0644 Flags: 0x80000 -Generation: 2438138670 Version: 0x00000000:00000001 -User: 0 Group: 0 Size: 26 -File ACL: 0 Directory ACL: 0 -Links: 1 Blockcount: 8 -Fragment: Address: 0 Number: 0 Size: 0 - ctime: 0x53d27172:a6792220 -- Fri Jul 25 08:02:10 2014 - atime: 0x546973cb:9c4270fc -- Sun Nov 16 20:04:27 2014 - mtime: 0x53ce8460:00000000 -- Tue Jul 22 08:33:52 2014 -crtime: 0x53d27168:18602e20 -- Fri Jul 25 08:02:00 2014 -Size of extra inode fields: 28 -EXTENTS: -(0):4822488 - -debugfs: imap <679618> # location of the inode -Inode 679618 is part of block group 82 - located at block 2622988, offset 0x0100 -``` +<script src="https://gist.github.com/franckcuny/016e6fc5be47a1fd4b4b.js"></script> There's many cools things you can do with inode, like using `man 1 find` to find a file based on it's inode instead of file name. @@ -231,61 +103,11 @@ gcc -g -o test test.c `valgrind` has an option `--tool` to use specific tool. Let's run valgrind with the **callgrind** tool, followed by `callgrind_annotate` to get a more readable output: -```bash -$ valgrind --tool=callgrind --simulate-cache=yes ./test -$ callgrind_annotate --auto=yes callgrind.out.11015 test.c --------------------------------------------------------------------------------- --- User-annotated source: test.c --------------------------------------------------------------------------------- -Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw - - . . . . . . . . . #include <stdio.h> - . . . . . . . . . - 3 0 1 1 0 0 1 . . int main() { - . . . . . . . . . FILE *fh; - . . . . . . . . . -11 4 4 . . . . . . if ((fh = fopen("/etc/issue", "r")) == NULL) { -59,650 14,454 661 107 1,079 49 106 868 42 => /build/buildd/eglibc-2.19/libio/iofopen.c:fopen@@GLIBC_2.2.5 (1x) -752 240 101 0 5 0 0 4 . => /build/buildd/eglibc-2.19/elf/../sysdeps/x86_64/dl-trampoline.S:_dl_runtime_resolve (1x) - . . . . . . . . . perror("fopen"); - . . . . . . . . . return 1; - . . . . . . . . . } - . . . . . . . . . - 8 4 3 0 1 . . . . fclose(fh); -791 246 101 0 43 7 0 2 . => /build/buildd/eglibc-2.19/elf/../sysdeps/x86_64/dl-trampoline.S:_dl_runtime_resolve (1x) -1,142 349 185 50 16 0 50 . . => /build/buildd/eglibc-2.19/libio/iofclose.c:fclose@@GLIBC_2.2.5 (1x) - 1 . . . . . . . . return 0; - 2 2 0 0 1 . . . . } -``` +<script src="https://gist.github.com/franckcuny/313fb41e150dfb28a2f7.js"></script> With the `--cache-sim=yes` option, we count all the instructions for read access, cache misses, etc. Another nifty tool is **cachegrind**, which shows the cache misses for different level of caches. -```bash -$ valgrind --tool=cachegrind ./test -==11710== Cachegrind, a cache and branch-prediction profiler -==11710== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote et al. -==11710== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info -==11710== Command: ./test -==11710== ---11710-- warning: L3 cache found, using its data for the LL simulation. ---11710-- warning: pretending that LL cache has associativity 30 instead of actual 20 -==11710== -==11710== I refs: 163,367 -==11710== I1 misses: 869 -==11710== LLi misses: 861 -==11710== I1 miss rate: 0.53% -==11710== LLi miss rate: 0.52% -==11710== -==11710== D refs: 54,700 (40,915 rd + 13,785 wr) -==11710== D1 misses: 2,940 ( 2,391 rd + 549 wr) -==11710== LLd misses: 2,406 ( 1,904 rd + 502 wr) -==11710== D1 miss rate: 5.3% ( 5.8% + 3.9% ) -==11710== LLd miss rate: 4.3% ( 4.6% + 3.6% ) -==11710== -==11710== LL refs: 3,809 ( 3,260 rd + 549 wr) -==11710== LL misses: 3,267 ( 2,765 rd + 502 wr) -==11710== LL miss rate: 1.4% ( 1.3% + 3.6% ) -``` +<script src="https://gist.github.com/franckcuny/71c1ae266b26aa8bf6e1.js"></script> ## The end diff --git a/_posts/2015-01-31-ubuntu-on-dell-xps13.md b/_posts/2015-01-31-ubuntu-on-dell-xps13.md index 502292c..aa39635 100644 --- a/_posts/2015-01-31-ubuntu-on-dell-xps13.md +++ b/_posts/2015-01-31-ubuntu-on-dell-xps13.md @@ -26,19 +26,7 @@ Sadly, there's still a few issues so far with Ubuntu 14.10: and there's some kind of issues where it get lost. But I think this is fixed with newer kernel (need to test). -```sh -mp saved to /sys/class/drm/card0/error -[ 1835.632679] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off -[ 1868.702435] psmouse serio1: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 1 -bytes away. -[ 1869.211965] psmouse serio1: resync failed, issuing reconnect request -[ 1876.689924] psmouse serio1: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 1 -bytes away. -[ 1877.198899] psmouse serio1: resync failed, issuing reconnect request -[ 1879.545191] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4 -[ 1879.546318] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 -[ 1879.558431] psmouse serio1: TouchPad at isa0060/serio1/input0 - driver resynced. -``` +<script src="https://gist.github.com/franckcuny/70b6959eef1892d00197.js"></script> But there's also the good stuff! @@ -59,8 +47,9 @@ But (and that's the main difference with Apple :), there's a and instructions on how to replace the wireless card. The good alternaties seems to be the [Intel 7260ngw](http://www.amazon.com/gp/product/B00GUNZUG0/) (I might replace the card). -For the curious, here’s the output of [dmesg](/files/dell-xps-2015-dmesg.txt) and -[lspci](/files/dell-xps-2015-lspci.txt). +For the curious, here’s the output of +[dmesg](https://gist.github.com/franckcuny/02da991e4b4c6bcaabef) and +[lspci](https://gist.github.com/franckcuny/bc9a486dc17e8c9acef1). I’ll update this page with more details / information in the next few weeks (I'm currently on a 3.16, I'll try the 3.18 during the weekend). |