[{"content":"I always wondered what leads to those lifelong friendships ?\nThe answer seems to lie in memories.\nThe foundation for any good friendship/relationship is built by memories shared between people. The memory can be a fun one or a boring one, but spending time and making that memory is vital.\nA boring memory is better than no memory at all. Those shared memories create the bond and more memories leads to a stronger bond.\nThe only catch is once you make them you can\u0026rsquo;t undo them. But that shouldn\u0026rsquo;t be the problem because, a boring memory is always better than no memory at all.\nSo go make those memories.\n","date":"2019-07-08","permalink":"https://www.forevergenin.com/posts/life/lessons/101/memories/","tags":["life","lessons","memories"],"title":"Life Lessons 101 - Memories"},{"content":"We will see how to generate a rootfs tarball for redhat based system. Since we are targetting redhat based system, I am going to use debian based system (Ubuntu 17.10 64-bit - latest at the time of writing this post) as my host. We will generate rootfs tarball for CentOS 7 64-bit.\nThe below mentioned steps are validated on Ubuntu 17.10 desktop installation.\nLets get started As usual the first step, install the required dependecy packages which in our case is yum.\nsudo apt install yum Second, will prepare the required directory structure. In our example ~/work will be our working directory and we will install the CentOS 7 roofs in inside of work in a directory named centos7.\nexport CENTOS\\_BASE\\_DIR=~/work export CENTOS\\_ROOT\\_DIR=${CENTOS\\_BASE\\_DIR}/centos7 mkdir -p ${CENTOS\\_ROOT\\_DIR} cd ${CENTOS\\_BASE\\_DIR} Now we need to generate the repo metadata file for CentOS 7 installation. Below code does the same.\ncat \u0026gt; ${CHROOT_BASE_DIR}/chroot-centos7.repo \u0026lt;\u0026lt; EOF [centos7-chroot-base] name=CentOS-7-Base baseurl=http://mirror.centos.org/centos/7/os/x86_64 gpgcheck=0 [centos7-chroot-epel] name=Extra Packages for Enterprise Linux 7 baseurl=http://dl.fedoraproject.org/pub/epel/7/x86_64 gpgcheck=0 EOF Once we have our directory structure and the repo file prepared as mentioned above, we can bootstrap the CentOS 7 root by executing the below mentioned command. This creates a base rootfs with networking utilities and sudo command.\nsudo yum -y -c chroot-centos7.repo --disablerepo=* \\ --enablerepo=centos7-chroot-base \\ --enablerepo=centos7-chroot-epel \\ --disableplugin=* \\ --installroot=${CHROOT_CENTOS7_BASE_DIR} install \\ bash \\ bash-completion \\ vim-minimal \\ yum \\ iproute \\ iputils \\ rootfiles \\ sudo After the yum installation is complete we need to prepare our rootfs for customization. We will start by mounting the required mount points to use chroot.\nsudo mount --bind /dev ${CHROOT_CENTOS7_BASE_DIR}/dev sudo mount --bind /dev/pts ${CHROOT_CENTOS7_BASE_DIR}/dev/pts sudo mount --bind /sys ${CHROOT_CENTOS7_BASE_DIR}/sys sudo mount --bind /proc ${CHROOT_CENTOS7_BASE_DIR}/proc sudo mount --bind /home ${CHROOT_CENTOS7_BASE_DIR}/home sudo cp /etc/resolv.conf ${CHROOT_CENTOS7_BASE_DIR}/etc/ Now we can start using the rootfs using chroot command. We will do the following customizations\nSetup releasever and basearch yum variables. Unfortunately this is required because of the caveat mentioned in Appendix I. Remove unncessary files like yum cache, locale definitions, temporary files, etc. Generate proper yum.conf, locale definition, build timestamp file and machine-id file - these are pretty standard stuff required for storage optimization in case we decide to use this rootfs for docker images sudo chroot ${CHROOT_CENTOS7_BASE_DIR} # Step no 1 echo \u0026quot;7\u0026quot; \u0026gt; /etc/yum/vars/releasever echo \u0026quot;x86_64\u0026quot; \u0026gt; /etc/yum/vars/basearch # Step no 2 yum clean all rm -rf /boot /var/cache/yum/* \\ /tmp/ks-script* \\ /var/log/* \\ /tmp/* \\ /etc/sysconfig/network-scripts/ifcfg-* ###Optional for making the rootfs lean to be used as base container umount /run systemd-tmpfiles --create --boot rm -f /var/run/nologin # Step no 3 echo 'container' \u0026gt; /etc/yum/vars/infra awk '(NF==0\u0026amp;\u0026amp;!done){print \u0026quot;override_install_langs='$LANG'\\ntsflags=nodocs\u0026quot;;done=1}{print}' \\ \u0026lt; /etc/yum.conf \u0026gt; /etc/yum.conf.new mv /etc/yum.conf.new /etc/yum.conf rm -f /usr/lib/locale/locale-archive #Setup locale properly localedef -v -c -i en_US -f UTF-8 en_US.UTF-8 /bin/date +%Y%m%d_%H%M \u0026gt; /etc/BUILDTIME :\u0026gt; /etc/machine-id ###End container After the rootfs configuration we need to umount all the mount points we mounted earlier. The unmount order is important here.\nsudo umount ${CHROOT_CENTOS7_BASE_DIR}/home sudo umount ${CHROOT_CENTOS7_BASE_DIR}/proc sudo umount ${CHROOT_CENTOS7_BASE_DIR}/sys sudo umount ${CHROOT_CENTOS7_BASE_DIR}/dev/pts sudo umount ${CHROOT_CENTOS7_BASE_DIR}/dev sudo rm ${CHROOT_CENTOS7_BASE_DIR}/etc/resolv.conf We do one last cleanup before we package the rootfs as a tarball.\nsudo rm -rf ${CHROOT_CENTOS7_BASE_DIR}/boot sudo rm -rf ${CHROOT_CENTOS7_BASE_DIR}/var/cache/yum/* sudo rm -f ${CHROOT_CENTOS7_BASE_DIR}/tmp/ks-script* sudo rm -rf ${CHROOT_CENTOS7_BASE_DIR}/var/log/* sudo rm -rf ${CHROOT_CENTOS7_BASE_DIR}/tmp/* sudo rm -rf ${CHROOT_CENTOS7_BASE_DIR}/etc/sysconfig/network-scripts/ifcfg-* And the final piece, run the below command to generate the CentOS 7 rootfs tarball.\nsudo tar --exclude=centos7/home \\ --exclude=centos7/var/cache/yum/* \\ -Jcvf centos7.tar.xz centos7 References Customizing yum variables Appendix I While running yum command inside of the CentOS 7 chroot I ran into below error message. Strangely this happens on Ubuntu host but not on CentOS host. As a fix I have created yum variables releasever and basearch inside the CentOS rootfs. Please check Reference section for the manual describing how to customize yum variables.\n$ yum search yum Failed to set locale, defaulting to C Loaded plugins: fastestmirror One of the configured repositories failed (Unknown), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work \u0026quot;fix\u0026quot; this: 1. Contact the upstream for the repository and get them to fix the problem. 2. Reconfigure the baseurl/etc. for the repository, to point to a working upstream. This is most often useful if you are using a newer distribution release than is supported by the repository (and the packages for the previous distribution release still work). 3. Run the command with the repository temporarily disabled yum --disablerepo=\u0026lt;repoid\u0026gt; ... 4. Disable the repository permanently, so yum won't use it by default. Yum will then just ignore the repository until you permanently enable it again or use --enablerepo for temporary usage: yum-config-manager --disable \u0026lt;repoid\u0026gt; or subscription-manager repos --disable=\u0026lt;repoid\u0026gt; 5. Configure the failing repository to be skipped, if it is unavailable. Note that yum will try to contact the repo. when it runs most commands, so will have to try and fail each time (and thus. yum will be be much slower). If it is a very temporary problem though, this is often a nice compromise: yum-config-manager --save --setopt=\u0026lt;repoid\u0026gt;.skip_if_unavailable=true Cannot find a valid baseurl for repo: base/$releasever/x86_64 $ ","date":"2017-11-16","permalink":"https://www.forevergenin.com/posts/linux/bootstrapping-centos-rootfs/","tags":["linux","rootfs","bootstrap","rpm","yum","redhat","centos","fedora"],"title":"Bootstrapping CentOS rootfs for use with chroots/containers"},{"content":"The aim this time is to setup a base rootfs for Ubuntu/Debian distro which can be used for setting up a chroot jail or to create a docker container base image. This blog is based on a earlier blog which I have written but forgot to publish around June, 2012.\nThe below mentioned steps are validated on Fedora 25 Workstation installation.\nFor setting up a debian based rootfs we need a tool called debootstrap. It\u0026rsquo;s available as part of EPEL repository for Fedora and other Redhat based distros. Make sure to always install the latest version of debootstrap.\nsudo dnf install debootstrap To setup a base rootfs you need to decide on the version of debian distro (wheezy, jessie, buster), the target architecture (i386 or amd64) and what kind of variant you want to setup. Do read the man page of debootstrap to know about more advanced options.\nFor this post, we are looking to setup a debian wheezy based rootfs to be used as amd64 build environment.\nsudo debootstrap --variant=buildd \\ --arch=amd64 \\ --components=main,contrib,non-free wheezy \\ wheezy-chroot \\ http://ftp.debian.org/debian/ # sudo debootstrap --variant=buildd \\ # --components=main,restricted,universe,multiverse \\ # --arch=amd64 precise \\ # precise-chroot \\ # http://archive.ubuntu.com/ubuntu In the above command components argument is used to specify which components to enable the distri repository. For debian, there are three components - main, contrib and non-free. We have enabled all three for our base rootfs.\nBut if you notice, the second line is slightly different because this points to the ubuntu repository and creates a rootfs for precise release of ubuntu. The components of ubuntu repository are named differently than the components of debian repository.\nNow if we want to customize our rootfs we can do so using the chroot command. For that we need to mount certain mount points and use the chroot command to enter and customize the rootfs.\nexport __CHROOT_DIR=${PWD}/wheezy-chroot sudo mount --bind /dev ${__CHROOT_DIR}/dev sudo mount --bind /dev/pts ${__CHROOT_DIR}/dev/pts sudo mount --bind /sys ${__CHROOT_DIR}/sys sudo mount --bind /proc ${__CHROOT_DIR}/proc #sudo mount --bind /home ${__CHROOT_DIR}/home # optional #sudo mount --bind /opt ${__CHROOT_DIR}/opt # optional sudo cp /etc/resolv.conf ${__CHROOT_DIR}/etc/resolv.conf # required for resolving DNS inside the chroot We are going to install sudo package inside the chroot.\nsudo chroot ${__CHROOT_DIR} export LC_ALL=C # this is to suppress the warning messages when we run apt-get install command apt-get install sudo Once the customization is done we need to properly unmount all the chroot mount points.\n#sudo umount ${__CHROOT_DIR}/opt #sudo umount ${__CHROOT_DIR}/home sudo umount ${__CHROOT_DIR}/dev/pts sudo umount ${__CHROOT_DIR}/dev sudo umount ${__CHROOT_DIR}/sys sudo umount ${__CHROOT_DIR}/proc sudo rm ${__CHROOT_DIR}/etc/resolv.conf In case you simply want to invoke a command inside the chroot skipping all the complex mount point setup you do so by running the command in the below mentioned format.\nsudo chroot wheezy-chroot apt-get install sudo As final step we can package the chroot as a tarball. It is recommended to clean the cache folder of the rootfs before creating the tarball.\nsudo rm -rf ${__CHROOT_DIR}/var/cache/apt/* sudo tar -Jcvf wheezy-chroot.tar.xz wheezy-chroot/ This will create a tarball named wheezy-chroot.tar.xz in the current directory. The newly created tarball can be used as base to create a new docker container or as a chroot jail.\nReferences http://wiki.debian.org/Debootstrap https://wiki.ubuntu.com/DebootstrapChroot ","date":"2017-09-20","permalink":"https://www.forevergenin.com/posts/linux/bootstrapping-debian-rootfs/","tags":["linux","rootfs","debootstrap","chroot","debian","ubuntu"],"title":"Bootstrapping a debian rootfs for use with chroots/containers"},{"content":"Goal We are looking to setup up a minimal forwarding DNS server on Ubuntu 16.04. After that we will see how to use nsupdate and dig to verify our configuration.\nPrerequisites A VM running Ubuntu 16.04 with BIND installed You need root access for the VM External DNS server information We are going to use google\u0026rsquo;s DNS servers (8.8.8.8 and 8.8.4.4) as our external servers. In case a query can\u0026rsquo;t be resolved by our DNS server it will forward the request to the external server. Domain information We need to know the domain topology we want our DNS server to manage. In this tutorial we are going to manage dev.lab domain using our DNS server Network information (optional) We need to know the network topology we which to use as part of our setup. For this example we will use a simple Class C network 192.168.1.0/24 Optionally you can setup a reverse DNS resolution but we are not going todo that today For our example we are going to use the below network configuration on the VM running the DNS service. The below code block represents the /etc/network/interfaces file from our VM which is going to run the DNS service.\n# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface enh0 inet static address 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.254 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 127.0.0.1 dns-search dev.lab DNS service setup We can install bind by running the following command from the termial.\napt install bind9 After installing bind we need configure the below listed files to make setup our domain dev.lab.\nFirst we will generate TSIG key for our domain by running the below command. These keys are required if you need to update your DNS records dynamicaly using a tool such as nsupdate. We will see the details in the later section.\ndnssec-keygen -a HMAC-MD5 -b 128 -n HOST dev.lab. After you run above mentioned command you should see two new files with names similiar to the ones listed below when you run ls -l command in your pwd.\n├── Kdev.lab.+157+08670.key └── Kdev.lab.+157+08670.private If you cat the above listed files you should see entries like the following two.\ndev.lab. IN KEY 512 3 157 6wYwnp6Y8oyg4H6HGWc2pw== Private-key-format: v1.3 Algorithm: 157 (HMAC_MD5) Key: 6wYwnp6Y8oyg4H6HGWc2pw== Bits: AAA= Created: 20170822164340 Publish: 20170822164340 Activate: 20170822164340 Backup of these files in a safe location. They are required in case you need to communicated with you DNS server via nsupdate in the future.\nSecond we will create a new db for the domain dev.lab. This files needs to be placed at /etc/bind/db.dev.lab with the exact same file name. The content of the file looks similiar to the one below. If you closely observe line numbers 15 to 17 you will see two CNAME entries and on A entry. Both dns and ntp entries are pointing to ns entry because we are planing to run both NTP and DNS services on the same machine.\n; BIND reverse data file for empty rfc1918 zone ; ; DO NOT EDIT THIS FILE - it is used for multiple zones. ; Instead, copy it, edit named.conf, and use that copy. ; $TTL\t86400 @\tIN\tSOA\tdev.lab. root.dev.lab. ( 1\t; Serial 604800\t; Refresh 86400\t; Retry 2419200\t; Expire 86400 )\t; Negative Cache TTL ; @\tIN\tNS\tns.dev.lab. dns\tIN\tCNAME\tns.dev.lab. ntp\tIN\tCNAME\tns.dev.lab. ns\tIN\tA\t192.168.1.1 After creating /etc/bind/db.dev.lab file make a softlink for the file /etc/bind/db.dev.lab inside /var/cache/bind.\nln -s /etc/bind/db.dev.lab /var/cache/bind/db.dev.lab As third step, we will configure the TSIG key and the bind it to the domain name dev.lab via zone entry. Create file /etc/bind/dev-lab.key with same content as shown in the below code block. Note that the line number 3 contains the TSIG key value which we generated previously.\nkey \u0026quot;dev.lab.\u0026quot; { algorithm hmac-md5; secret \u0026quot;6wYwnp6Y8oyg4H6HGWc2pw==\u0026quot;; }; Now append the below configuration to the /etc/bind/named.conf.local to bind the TSIG key and dev.lab domain. The zone entry basically lists where is the db file for dev.lab domain is located and which key to use for authenticating while modifying the entries for the domain dev.lab dynamically.\ninclude \u0026quot;/etc/bind/dev-lab.key\u0026quot;; zone \u0026quot;dev.lab.\u0026quot; { type master; notify no; file \u0026quot;/var/cache/bind/db.dev.lab\u0026quot;; allow-update { key \u0026quot;dev.lab.\u0026quot;; }; }; And for the final step, we will configure the forward DNS server entries in case our DNS server could\u0026rsquo;t resolve a particular domain request. For this we need to add forwarders block to /etc/bind/named.conf.options file. Note the line numbers 13 to 16.\noptions { directory \u0026quot;/var/cache/bind\u0026quot;; // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See http://www.kb.cert.org/vuls/id/800113 // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing // the all-0's placeholder. forwarders { 8.8.8.8; 8.8.4.4; }; forward only; //======================================================================== // If BIND logs error messages about the root key being expired, // you will need to update your keys. See https://www.isc.org/bind-keys //======================================================================== dnssec-enable no; dnssec-validation no; dnssec-lookaside no; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; listen-on { 127.0.0.1; 192.168.1.1; }; }; By default bind listens only on 127.0.0.1. But for our use case we need this server to be accessible from all the clients connected to 192.168.1.0/24 subnet. For this you need to add our VM\u0026rsquo;s ip address to the listen block (line number 32). Now if you want your DNS server to serve DNS requests from clients connected to network other than 192.168.1.0/24 google for how to configure and use allow-query / allow-query-cache blocks.\nWith this the configuration portion is complete for our domain dev.lab. To start/restart the DNS server run the below command.\nsystemctl restart bind9 You can get to know the status of the service by running systemctl status bind9\nVerifying the DNS setup We will see how to validate our DNS server is working as expected using two simple commands nsupdate and dig.\nVerifying DNS domain setup We can verify our domain dev.lab is setup properly by adding and removing DNS entries.\nAdding a new DNS entry To add a new DNS entry invoke nsupdate followed by below instruction. The below instructions add nfs.dev.lab as domain name to the ip address 192.168.1.2.\nNote the key used in third line is the same TSIG key we generated and configured for our domain dev.lab in the above section.\ndebug yes server 192.168.1.1 key dev.lab 6wYwnp6Y8oyg4H6HGWc2pw== update add nfs.dev.lab 86400 a 192.168.128.2 send Deleting a DNS entry To remove an existing entry invoke nsupdate with following commands\ndebug yes server 192.168.1.1 key dev.lab 6wYwnp6Y8oyg4H6HGWc2pw== update delete nfs.dev.lab 86400 a 192.168.128.2 send We can mix match the use of add and delete statements. For example the below list of instructions for nsupdate is perfectly valid.\ndebug yes server 192.168.1.1 key dev.lab 6wYwnp6Y8oyg4H6HGWc2pw== update add nfs.dev.lab 86400 a 192.168.128.2 update delete nfs.dev.lab 86400 a 192.168.128.2 update add nfs.dev.lab 86400 a 192.168.128.3 send Verifying DNS entries and DNS forwarding To verify a DNS entry added to the server execute dig @192.168.1.1 nfs.dev.lab and you should get an output similiar to the below one:\n; \u0026lt;\u0026lt;\u0026gt;\u0026gt; DiG 9.10.3-P4-Ubuntu \u0026lt;\u0026lt;\u0026gt;\u0026gt; @192.168.1.1 nfs.dev.lab ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -\u0026gt;\u0026gt;HEADER\u0026lt;\u0026lt;- opcode: QUERY, status: NOERROR, id: 24342 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;nfs.dev.lab.\tIN\tA ;; ANSWER SECTION: nfs.dev.lab. 86400 IN\tA\t192.168.128.2 ;; AUTHORITY SECTION: dev.lab.\t86400\tIN\tNS\tns.dev.lab. ;; ADDITIONAL SECTION: ns.dev.lab.\t86400\tIN\tA\t192.168.1.1 ;; Query time: 0 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Tue Aug 22 23:10:16 IST 2017 ;; MSG SIZE rcvd: 104 To verify the forward DNS functionality execute the above command requesting an resolution to a domain other than dev.lab. For example, dig @192.168.1.1 gitlab.com should produce an output similiar to the below one.\n; \u0026lt;\u0026lt;\u0026gt;\u0026gt; DiG 9.10.3-P4-Ubuntu \u0026lt;\u0026lt;\u0026gt;\u0026gt; @192.168.1.1 github.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -\u0026gt;\u0026gt;HEADER\u0026lt;\u0026lt;- opcode: QUERY, status: NOERROR, id: 44220 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 26 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;github.com.\tIN\tA ;; ANSWER SECTION: github.com.\t35\tIN\tA\t192.30.255.112 github.com.\t35\tIN\tA\t192.30.255.113 ;; AUTHORITY SECTION: com.\t45434\tIN\tNS\tb.gtld-servers.net. com.\t45434\tIN\tNS\td.gtld-servers.net. com.\t45434\tIN\tNS\ta.gtld-servers.net. com.\t45434\tIN\tNS\te.gtld-servers.net. com.\t45434\tIN\tNS\tj.gtld-servers.net. com.\t45434\tIN\tNS\tg.gtld-servers.net. com.\t45434\tIN\tNS\tl.gtld-servers.net. com.\t45434\tIN\tNS\tm.gtld-servers.net. com.\t45434\tIN\tNS\th.gtld-servers.net. com.\t45434\tIN\tNS\tf.gtld-servers.net. com.\t45434\tIN\tNS\tc.gtld-servers.net. com.\t45434\tIN\tNS\ti.gtld-servers.net. com.\t45434\tIN\tNS\tk.gtld-servers.net. ;; ADDITIONAL SECTION: a.gtld-servers.net.\t87848\tIN\tA\t192.5.6.30 a.gtld-servers.net.\t87848\tIN\tAAAA\t2001:503:a83e::2:30 b.gtld-servers.net.\t20034\tIN\tAAAA\t2001:503:231d::2:30 c.gtld-servers.net.\t115424\tIN\tA\t192.26.92.30 c.gtld-servers.net.\t115424\tIN\tAAAA\t2001:503:83eb::30 d.gtld-servers.net.\t18843\tIN\tA\t192.31.80.30 d.gtld-servers.net.\t18399\tIN\tAAAA\t2001:500:856e::30 e.gtld-servers.net.\t110668\tIN\tA\t192.12.94.30 e.gtld-servers.net.\t110668\tIN\tAAAA\t2001:502:1ca1::30 f.gtld-servers.net.\t97272\tIN\tA\t192.35.51.30 f.gtld-servers.net.\t147976\tIN\tAAAA\t2001:503:d414::30 g.gtld-servers.net.\t145988\tIN\tA\t192.42.93.30 g.gtld-servers.net.\t43547\tIN\tAAAA\t2001:503:eea3::30 h.gtld-servers.net.\t97403\tIN\tA\t192.54.112.30 h.gtld-servers.net.\t97403\tIN\tAAAA\t2001:502:8cc::30 i.gtld-servers.net.\t10551\tIN\tA\t192.43.172.30 i.gtld-servers.net.\t10669\tIN\tAAAA\t2001:503:39c1::30 j.gtld-servers.net.\t11797\tIN\tA\t192.48.79.30 j.gtld-servers.net.\t11797\tIN\tAAAA\t2001:502:7094::30 k.gtld-servers.net.\t74153\tIN\tA\t192.52.178.30 k.gtld-servers.net.\t74153\tIN\tAAAA\t2001:503:d2d::30 l.gtld-servers.net.\t110299\tIN\tA\t192.41.162.30 l.gtld-servers.net.\t109769\tIN\tAAAA\t2001:500:d937::30 m.gtld-servers.net.\t127321\tIN\tA\t192.55.83.30 m.gtld-servers.net.\t125906\tIN\tAAAA\t2001:501:b1f9::30 ;; Query time: 44 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Tue Aug 22 23:12:23 IST 2017 ;; MSG SIZE rcvd: 851 References How To Configure Bind as a Caching or Forwarding DNS Server on Ubuntu 14.04 - from Digital Ocean blog How To Configure BIND as a Private Network DNS Server on Ubuntu 14.04 - from Digital Ocean blog nsupdate - linux man page dig - linux man page ","date":"2017-08-22","permalink":"https://www.forevergenin.com/posts/networking/forwarding-dns-server-setup/","tags":["ubuntu","dns","bind9","dnssec","nsupdate","digg"],"title":"Forwarding DNS server on Ubuntu 16.04"},{"content":"This check-list tries to document the obvious, to reduce the time spent fixing toolchain related errors while cross compiling.\nExport the toolchain location to the PATH environment variable Set proper --sysroot for CFLAGS, CXXFLAGS and LDFLAGS Set proper PKG_CONFIG_SYSROOT_DIR, PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR for pkg-config tool. This is important for build scripts which use pkg-config to determine the proper build flags. Note: Use pkg-config \u0026gt;= 0.26 . There is bug with previous versions of pkg-config which ignores the PKG_CONFIG_SYSROOT_DIR value\nA sample configuration export __CB_TOOLCHAIN_DIR=/opt/cross-toolchain export __CB_TOOLCHAIN_SYSROOT=${__CB_TOOLCHAIN_DIR}/sysroot export PATH=${__CB_TOOLCHAIN_DIR}/bin:${PATH} export PKG_CONFIG_SYSROOT_DIR=${__CB_TOOLCHAIN_SYSROOT} export PKG_CONFIG_PATH=${PKG_CONFIG_SYSROOT_DIR}/usr/lib/pkgconfig export PKG_CONFIG_LIBDIR=${PKG_CONFIG_SYSROOT_DIR}/usr/lib/pkgconfig export CFLAGS+=\u0026quot;--sysroot=${__CB_TOOLCHAIN_SYSROOT} \u0026quot; export CXXFLAGS+=\u0026quot;--sysroot=${__CB_TOOLCHAIN_SYSROOT} \u0026quot; export LDFLAGS+=\u0026quot;--sysroot=${__CB_TOOLCHAIN_SYSROOT} \u0026quot; #export PKG_CONFIG_DEBUG_SPEW=true # this one is for debugging pkg-config Note : Need to update the post on how to cross compile packages which use autoconf tools\n","date":"2016-10-13","permalink":"https://www.forevergenin.com/posts/linux/cross-compilation-checklist/","tags":["linux","build"],"title":"Cross Compilation Checklist"},{"content":"Until few years back setting up Java development environment based on Sun/Oracle JDK was fairly a simple task. Since most of the linux distributions included Oracle/Sun JDK as part of their default package repository (here read as Canonical\u0026rsquo;s partner repository ;-)) it was as easy as installing any other core linux pacakge. But in recent times due to license restrictions Oracle JDK is not included in any of the linux distribution repositories by default. Setting up Java development environment manually from scratch on linux has become a tedious job (though still easier doing tha on Microsoft Windows). Nowadays I avoid doing it, given a chance to use a preconfigured virtual machines or chroot tar balls - created specifically for development/build requirements.\nAs for the intent of this post, it is to serve as a guide on best practices of setting up a Java development / build environment from scratch if such need arises in the future.\nPrerequisites:\nOracle JDK version of your choice (in our case v1.7.0_79_) Apache Ant version of your choice (in our case 1.9.7) )which works with the JDK version chosen in step 1 Apache Maven version of your choice (in our case 3.0.5) which works with the JDK version chosen in step 1 Gradle version of your choice (in our case 2.13) which works with the JDK version chosen in step 1 Download tar ball archives of all the above packages. RPM package is available for Oracle JDK but it kills the \u0026ldquo;distro independent\u0026rdquo; part of this post.\nExtract all the tar balls to a location of your convenience. If I have root or sudo access (which happens to be most of the time), I usually prefer /opt/tools/java.\nAfter completing the extraction of tarballs to the /opt/tools/java direcory add the environment config scripts based on the below given template to /etc/profile.d directory of you linux file system.\n00700_java_home.sh if [ -z ${JAVA_HOME} ]; then export JAVA_HOME=/opt/tools/java/jdk1.7.0_79 export PATH=${PATH}:${JAVA_HOME}/bin fi 00701_ant_home.sh if [ -z ${ANT_HOME} ]; then export ANT_HOME=/opt/tools/java/apache-ant-1.9.7 export PATH=${PATH}:${ANT_HOME}/bin fi 00702_m2_home.sh if [ -z ${M2_HOME} ]; then export M2_HOME=/opt/tools/java/apache-maven-3.0.5 export PATH=${PATH}:${M2_HOME}/bin fi 00703_gradle_home.sh if [ -z ${GRADLE_HOME} ]; then export GRADLE_HOME=/opt/tools/java/gradle-2.13 export PATH=${PATH}:${GRADLE_HOME}/bin fi At the end of the setup, your /etc/profile.d directory should look something like this\n/etc/profile.d ├── 00700_java_home.sh ├── 00701_ant_home.sh ├── 00702_m2_home.sh └── 00703_gradle_home.sh And your /opt/tools/java should look something like this\n/opt/tools/java ├── apache-ant-1.9.7 ├── apache-maven-3.0.5 ├── gradle-2.13 └── jdk1.7.0_79 ","date":"2016-06-01","permalink":"https://www.forevergenin.com/posts/linux/distro-independent-java-development-environment-setup/","tags":["linux","java","development","maven","ant","gradle"],"title":"Distro independent Java development environment setup"},{"content":" Dear Mr. Vernon, we accept the fact that we had to sacrifice a whole Saturday in detention for whatever it was we did wrong. What we did was wrong. But we think you\u0026rsquo;re crazy to make us write an essay telling you who we think we are. You see us as you want to see us—in the simplest terms, in the most convenient definitions. But what we found out is that each one of us is a brain and an athlete and a basket case a princess and a criminal.\nDoes that answer your question? Sincerely yours, the Breakfast Club.\nDedicated to all my appraisers ;-)\n#YearEnd\n","date":"2015-05-09","permalink":"https://www.forevergenin.com/posts/rants/the-breakfast-club/","tags":["rants","the breakfast club","quotes"],"title":"The Breakfast Club"},{"content":"Finally, after much deliberation I have decided to spend some time on maintaining a personal blog (more about this decision later). Now the question is what should be my first post? Much like most of the decisions I have made in my life I left this one as well to randomness and I stumbled upon this article at Kotaku.\nThough it was my first manga, the truth is I was not worried much about the end. In fact I felt a sense of relief considering the recent decline in the quality of Naruto storyline. Good or bad, all things must come to an end.\n","date":"2014-11-04","permalink":"https://www.forevergenin.com/posts/manga/naruto-comes-to-an-end/","tags":["naruto","manga"],"title":"Naruto comes to an end"}]