3 ms·

I am on 13.10 with xmonad but will try to move to 14.04 LTS with Unity. This will happen as soon as I finish my Ansible playbook to get all my current Ubuntu t

by AhtiK 13y ago

I am on 13.10 with xmonad but will try to move to 14.04 LTS with Unity. This will happen as soon as I finish my Ansible playbook to get all my current Ubuntu tweaks and dev env setup implemented so I have a repeatable setup and can safely do a fresh install of my desktop as needed with zero manual work. Dotfiles alone didn't cut it and VPS provisioning frameworks like Ansible are great examples how desktops could be built as well :-) Feel free to track the progress at https://github.com/ahtik/dotdotbox https://github.com/ahtik/dotdotbox I'll try to keep it as universal as possible so it can be shared and tweaked in collaboration.

dmix 13y ago
I've wanted to be able to automate setting up a new Linux desktop on a new laptop for a long time. It's a drag setting up a new box, it takes nearly a month to get everything tweaked right after I switch to a new distro (which is far more often that I should be responsibly doing it). I've been thinking about setting up an Ansible script, I've never used it before though. How would this work on a new machine? Is it something you run post-OS install? I want to try it out with Arch Linux.
- AhtiK 13y ago
  Yes, a playbook would run post-OS install. It's either executed locally or anything you can SSH to. If being careful enough one can support multiple OS-s with the same playbook (at least different Linux flavors) but it's definitely quite some maintenance like different package names and conf file locations etc. A playbook contains tasks like installing, removing packages, editing config files etc. The beauty of it is that if done correctly you can run the same playbook over and over again against the same computer and each task can be smart enough to know if it needs to be run or not. This makes updating your computer with the same or updated playbook very fast. With Ubuntu it's easy to get to the post-OS install, it's more involved with Arch Linux. I would first create an Arch box with Vagrant using Virtualbox. And then create a playbook that works with that virtual Arch box. If the box and ansible playbook is good enough then https://wiki.archlinux.org/index.php/Moving_an_existing_install_into_(or_out_of)_a_virtual_machine https://wiki.archlinux.org/index.php/Moving_an_existing_inst... At least in theory, I haven't moved Arch between VM and a real host myself... Of course you can also just do a manual Arch install and then run the playbook but that would miss half the fun of doing less by doing more.
- e12e 13y ago
  I'm not sure Ansible would be very useful for the use-case of "getting your desktop right". Generally there's three things that is needed to get a (personal) dekstop set up: 1) Get the right packages (eg: dpkg --get-selections > my-pacakges.list; dpkg --set-selections < my-packages.list). This part ansible can do fine -- but not really any better than your distributions package tool (for this particular use-case) 2) Set up your account (This can be done with kicstart, FAI or preseed.cfg) If you only have one user, this might not be worth automating. This is also a task ansible can handle fine. 3) Set up your preferences/restore your home folder etc. This is the area that tends to take the most time and care. Personally I've pretty much stabilized on a very spartan xmonad config (driven from ~/.xsession), and have a mercurial repo with various dot-files that I just clone and symlink to (and I have a bash-script that takes care of setting up the symlinks) -- I also manually set up a python virtualenv (which bin I add to my path), an ~/opt hierarchy managed by xstow (I usually recreate this, as the whole point is to follow upstream, unpackaged software) and a ~/bin folder that's also in a mercurial repo (a few shell scripts for toggling vga/internal displays for my laptop and some similar small utilities). Now, "manually" symlinking your dot-files probably isn't the best idea -- the main reason I do it this way, is that I've had to manage my profile across different distributions (and for a time also on Solaris) -- and then just keeping home in version control can be a little to simplistic (now with mercurial/git I suppose using named branches for the various machines might be a viable option though -- not sure if I want a check-out command in my .bashrc/.xsession though -- too much can go wrong... eg if git/mercurial for some reason isn't available won't run without errors...).

by AhtiK 13y ago

dmix 13y ago

I've wanted to be able to automate setting up a new Linux desktop on a new laptop for a long time. It's a drag setting up a new box, it takes nearly a month to get everything tweaked right after I switch to a new distro (which is far more often that I should be responsibly doing it). I've been thinking about setting up an Ansible script, I've never used it before though. How would this work on a new machine? Is it something you run post-OS install? I want to try it out with Arch Linux.

AhtiK 13y ago
Yes, a playbook would run post-OS install. It's either executed locally or anything you can SSH to. If being careful enough one can support multiple OS-s with the same playbook (at least different Linux flavors) but it's definitely quite some maintenance like different package names and conf file locations etc. A playbook contains tasks like installing, removing packages, editing config files etc. The beauty of it is that if done correctly you can run the same playbook over and over again against the same computer and each task can be smart enough to know if it needs to be run or not. This makes updating your computer with the same or updated playbook very fast. With Ubuntu it's easy to get to the post-OS install, it's more involved with Arch Linux. I would first create an Arch box with Vagrant using Virtualbox. And then create a playbook that works with that virtual Arch box. If the box and ansible playbook is good enough then https://wiki.archlinux.org/index.php/Moving_an_existing_install_into_(or_out_of)_a_virtual_machine https://wiki.archlinux.org/index.php/Moving_an_existing_inst... At least in theory, I haven't moved Arch between VM and a real host myself... Of course you can also just do a manual Arch install and then run the playbook but that would miss half the fun of doing less by doing more.
e12e 13y ago
I'm not sure Ansible would be very useful for the use-case of "getting your desktop right". Generally there's three things that is needed to get a (personal) dekstop set up: 1) Get the right packages (eg: dpkg --get-selections > my-pacakges.list; dpkg --set-selections < my-packages.list). This part ansible can do fine -- but not really any better than your distributions package tool (for this particular use-case) 2) Set up your account (This can be done with kicstart, FAI or preseed.cfg) If you only have one user, this might not be worth automating. This is also a task ansible can handle fine. 3) Set up your preferences/restore your home folder etc. This is the area that tends to take the most time and care. Personally I've pretty much stabilized on a very spartan xmonad config (driven from ~/.xsession), and have a mercurial repo with various dot-files that I just clone and symlink to (and I have a bash-script that takes care of setting up the symlinks) -- I also manually set up a python virtualenv (which bin I add to my path), an ~/opt hierarchy managed by xstow (I usually recreate this, as the whole point is to follow upstream, unpackaged software) and a ~/bin folder that's also in a mercurial repo (a few shell scripts for toggling vga/internal displays for my laptop and some similar small utilities). Now, "manually" symlinking your dot-files probably isn't the best idea -- the main reason I do it this way, is that I've had to manage my profile across different distributions (and for a time also on Solaris) -- and then just keeping home in version control can be a little to simplistic (now with mercurial/git I suppose using named branches for the various machines might be a viable option though -- not sure if I want a check-out command in my .bashrc/.xsession though -- too much can go wrong... eg if git/mercurial for some reason isn't available won't run without errors...).