Your SlideShare is downloading. ×
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Using virtualisation and pkgsrc in heterogeneous networks
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Using virtualisation and pkgsrc in heterogeneous networks

735

Published on

In an environment where heterogeneity cannot be avoided, pkgsrc's portability allows the system administrator to easily deploy a uniform set of packages across all architectures and systems. …

In an environment where heterogeneity cannot be avoided, pkgsrc's portability allows the system administrator to easily deploy a uniform set of packages across all architectures and systems. Virtualisation helps cutting down the costs of building and maintaining the packages.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
735
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Using virtualisation and pkgsrc Quentin Garnier pkgsrcCon 2007 April 27th, 2007
  • 2. Who, Why, Where, When?
    • I manage all IT at an EDA company named EVE
    • 2 different needs
      • packages for my NetBSD servers
      • work environment for R&D on Linux
      • Goal is the same: save space and CPU
    • Bulk building under Xen for my NetBSD servers for the past 3 years
    • The Linux part is recent, and still work in progress
  • 3. Why Xen?
    • For the NetBSD part, because there isn't really a choice
    • Experience with it on Linux, although VMWare is probably a good alternative
    • Intense cool free software factor
  • 4. Xen terminology
    • Paravirtualisation (PV)
      • Requires a special kernel in the virtual machine
    • Full virtualisation
      • FV machines are often called HVM
      • Requires special support from the CPU
      • Any OS can run, the hardware of the HVM is emulated by QEMU
    • Dom0 vs. DomU
  • 5. Packages for servers: why
    • Not to waste a real machine on an infrequent need
    • PV can be used for NetBSD packages
      • NetBSD supports Xen 2 since release 3.0
      • Userland is no different to NetBSD/i386
  • 6. Packages for servers: how
    • Details of the management of the packages once built is irrelevant
      • Meta-packages for each server
      • Options are common for all servers
      • Management is easy but not very incremental
      • Stoned described a much better solution last year to manage packages
  • 7. Packages for servers: caveat
    • My servers run NetBSD 2.0.3_STABLE
      • Kernel version inside the PV domain must be faked
    • I have upgraded my workstation to the post newlock2 era
      • Feel the binary compatibility breakage pain
      • Considering a SA compatibility stub
  • 8. Performance
    • Host is a Pentium 4 2.6 GHz
      • VMs get 384MB of memory
    • Rarely takes more than a few hours
      • Lots of packages don't change often
      • Doing nothing takes more than 30 minutes
  • 9. Linux at EVE (1)
    • Theoretically, only support for RedHat 8 and RedHat Enterprise Linux 3
    • Practically, what our beloved clients use
      • E.g., Very Important Client (VIC) uses SuSE Linux Enterprise Server 9
      • They have their own toolchain, incidentally needing support for libstdc++.so.6
      • Lots of requests for RHEL 4, SuSE 10
    • Heterogeneous network
  • 10. Linux at EVE (2)
    • Plan to support only libstdc++.so.6 and x86_64 in HEAD
      • But we still have to support older versions of our software for some time, notably for VIC
    • Developers need a consistent environment
    • QA needs specific tools in all environments
  • 11. First attempt
    • I tried the “greatest common divisor” approach
      • Packages compiled on rh8-i386
      • PREFER_PKGSRC set to yes, with a few exceptions
    • pam-ldap is teh shit
      • the compiled sudo doesn't work on SLES9
  • 12. Current attempt
    • Virtualisation helps consolidating the resources
    • The machines wouldn't have to be up all the time anyway
    • 8 platforms to support initially:
      • rh8-i386, rhel{3,4}-{i386,amd64}
      • sles9-i386, sles10-{i386,amd64}
      • More to come (e.g., rhel5-amd64), some to go away
  • 13. Virtualisation as the obvious solution
    • I don't have much resources to affect to that task
    • Performance is never an issue
      • Security of packages such as firefox are not a top priority
    • Developers can access a pristine environment for each platform, for tests with our software
  • 14. Hardware configuration
    • 4-core machine seems enough
      • cheap enough for a bi-Xeon 51xx
      • 4GB of memory, reserving ~1GB for dom0
      • 3 or 4 running HVMs
    • Dom0 gets its own CPU, in order to help (slightly) with I/Os
    • Each VM gets a 8GB LVM volume as its disk
      • The rest is served by dom0 through NFS
      • Not enough for rhel4-amd64!
  • 15. Installations of Linux in the HVMs
    • RedHat 8 was a real pain
      • Installation kernel crashed
      • Latest RedHat 8 kernel would freeze during installation, and would have a lot of trouble keeping time afterwards
    • Others went more or less easy
      • Time keeping under Xen/QEMU is hard, NTP is required
      • 2.6 kernels are much better
  • 16. Configuration of the Linux HVMs
    • Network
    • Mount points
      • /auto/pkg
      • /pkgbuild/src
      • /pkgbuild/obj
    • NTP
    • pkg_install
    • poweroff
  • 17. Configuration of pkgsrc
      • _EVE_HOST!= hostname -s
      • PKG_DBDIR= /auto/pkg/${_EVE_HOST}/db
      • LOCALBASE= /auto/pkg/${_EVE_HOST}/base
      • VARBASE= /auto/pkg/${_EVE_HOST}/var
      • PKG_TOOLS_BIN= /auto/pkg/${_EVE_HOST}/base/sbin
      • PKGMANDIR= man
      • FETCH_CMD= /auto/pkg/${_EVE_HOST}/base/bin/ftp
      • TOOLS_PLATFORM.pax?= /auto/pkg/${_EVE_HOST}/base/bin/pax
      • TOOLS_PLATFORM.tar?= /bin/tar
      • WRKOBJDIR= /pkgbuild/obj/obj
      • OBJHOSTNAME= yes
      • DISTDIR= /pkgbuild/obj/dist/${_EVE_HOST}
      • PACKAGES= /pkgbuild/obj/packages/${_EVE_HOST}
      • PKG_OPTIONS.sudo= ldap pam
      • PKG_OPTIONS.libgnomeprint= cups
      • PKG_OPTIONS.evolution= ssl
      • BULKFILESDIR= /pkgbuild/obj/bulk/files/${_EVE_HOST}
      • ALLOW_VULNERABLE_PACKAGES= yes
      • _ACCEPTABLE= yes
      • CFLAGS+= -pipe
      • CXXFLAGS+= -pipe
  • 18. Installation of packages
    • /auto/pkg is what end clients see
    • The mount point the build VMs see is only for building
    • The actual /auto/pkg is populated by rsync on the dom0
  • 19. Built packages
    • seamonkey, evolution, thunderbird, firefox
      • Those takes a lot of time
    • gcc4
      • Not so hard to compile, but takes ages to extract
    • bvi, gtkwave, some Perl packages
  • 20. pkgsrc issues (1)
    • Linux/x86_64 support is poor
      • buildlink3 lacks knowledge of ${ABI_SUFFIX}
      • x11-links, too
    • devel/autoconf213 errors out on SLES9
      • I have to rebuild autoconf for all the Gecko packages
    • openoffice2-bin doesn't support x86_64
      • But I make it install 32bits binaries
  • 21. pkgsrc issues (2)
    • Trying a release branch, 2007Q1
      • Immediately stumbled upon an issue fixed in HEAD but for which the committer didn't request a pull-up
    • RedHat wants you to use openssl.pc
    • Firefox plug-ins packages can't use a native firefox
  • 22. pkgsrc issues (3)
    • Build of Gecko packages break at some point on Linux/x86_64
      • Doing “make build” again works, but it's not possible during a bulk build
    • The rest in related to packages behaving in a special way on Linux
      • fake Xfixes.pc expected
      • gnutls and ld version script
      • gnome-vfs2 and krb5
      • acroread and pax-as-tar
  • 23. Xen-related issues
    • Passed the installation, time-keeping and poweroff issues, everything is just fine
    • Controlling domains go through a mix of two different sets of C APIs and a Python API
      • No documentation whatsoever, of course
      • Thus that part is still in early stages
  • 24. Performance
    • Takes slightly more than 24 hours on rhel4-i386 for the build of all my packages
    • rhel3-i386 takes a lot longer
    • rh8-i386 takes very, very, very long
      • although it uses the same kernel as rhel3-i386
      • build launched on Monday still isn't finished
  • 25. Conclusion
    • Still a lot of work is needed to automate things
      • But first I'd like all packages to compile on all platforms...
      • Squid is still not correctly configured
    • pkgsrc is the ideal solution to the problem at stake, and it's not just zealotism
    • Virtualisation answers a very specific need nicely, but it's not perfect
  • 26. Questions and comments
    • There are probably many ways of improving that system...

×