On 07/12/2011 09:23 PM, Mike O'Connor wrote: >> Remember that the goal is to provide a helper to quickly disable port >> forwarding. It does work on a freshly installed server. I don't mind >> improving the script if you can think of improvements. How would you do >> it then? > > Do you understand why these are currently inadequate? If so, I'd hope > they'd be trivial to imporove.
Are we doing a cat and mouse game here? I will reiterate: what is your suggestion? Something like a grep -v to remove any lines with the directive, then adding it at the end of the file? This would work, but would also remove any commented out directive. A sed -i wouldn't be any better to me. I can't think of any solution that would be 100% clean, and this never has been the goal anyway. It's just a time saver, and also points to the administrator what should be done. In fact, I would expect an experienced administrator to have a look to the script content. Maybe that's a wrong assumption? >> The /usr/share/dtc-xen-os is a repository of OS templates that can be >> installed automatically by dtc-xen (see "man dtc_reinstall_os", >> particularly the -os option). Of course, these aren't available in >> Debian, I don't see the security team doing the security updates of >> other distributions (and frankly, the images we provide are on the best >> effort basis, some should be upgraded). > > dtc_reinstall_os would download them? how do I do that? Am I to > understand that I would run dtc_reinstall_os with some parameters after > installing the package, but before running dtc-xen_finish_install? If > so, shouldn't this be mentioned somewhere? (If it is, please show me where). No. What you'd do would be adding the repository where the templates are, then install them in your system. For example: apt-get install dtc-xen-os-ubuntu-amd64-9.04 dtc-xen-os-suse-11.1-x86-64 dtc-xen-os-netbsd5-amd64 dtc-xen-os-elastix-centos5.5-amd64 from my repository would bring the following folders in /usr/share/dtc-xen-os: elastix-centos5.5-amd64 suse-11.1-x86-64 ubuntu-amd64-9.04 Each folder contains 3 scripts: custom_os install_os setup_network. install_os would unpack an eventual archive (tar.gz or a .img) in the target LVM partition, custom_os takes care of editing /etc/fstab, and setup_network does the network setup (in /etc/network/interfaces for the case of a Debian / Debian derivative, for example). As for the NetBSD one, it adds the NetBSD Xen-enabled domU kernels in /boot, so that you can run NetBSD. All these, we ship them as Debian packages because it's a lot faster to deploy and share this way. I believe this is well documented on our wiki, and I can't recall anyone that didn't understand how it worked. Do you think I should mention the wiki in a README.Debian? >>> Then you tell the user that they should add a sources.list entry for a third >>> party repsitory which seems to have packages for lenny ?!? Why is this. >>> Are >>> there packages in this repository that are needed for using dtc-xen? >> >> Yes, see above. The packages in the repository for Lenny are working >> without any issue in any Debian release anyway, it's just some tar.gz >> and some tiny scripts to do the setup of these images. > > Is it the case that we can expect any user of this software to want > those scripts and .tar.gzs? You don't HAVE to use these images. By default, DTC-Xen is using debootstrap and yum to install Debian (you can select which release) and CentOS, which may well be enough. I did take over the maintenance of yum because I needed to build chroot dynamically for this reason (and because the old maintainer was gone MIA as well). >>> It appears that since /usr/share/dtc-xen-os doens't exist, you will then >>> tell the user to run: >>> "apt-get install" >>> >>> Which seems rather pointless. were you going to tell them to apt-get >>> update? >>> apt-key add? >> >> The idea is to give pointers to the user that there are some image >> templates available. I agree that the message needs to be updated, and I >> will. But now, do you really think that an administrator wouldn't know >> how to use apt? > > Well, the rest of this script is making assumptions that given pointers > the administrator isn't able to make changes to sudoers or sshd_config, > so, I dunno, you tell me. No, this script isn't making such assumptions. I don't understand how you reached that conclusion. The script is just there to do things faster than with a text editor. It's a helper, nothing more. It's not designed to be very clean either. You don't have to use it if you don't feel like it. Doing things "by hand" is ok too. But one thing for sure: if you are granting access to virtual machines to untrusted users, you should avoid at all costs to enable the sudoers thing (which opens the ssh for the virtual users) without removing the port forwarding, because that's a security issue (using port forwarding, you can access the tty1 of another VM, and do all sorts of nasty things). By the way, I've added more echo in the script to explain the above, and to suggest the administrator to inspect the result. Please have a look to the new version, and let me know what you think: http://git.gplhost.com/gitweb/?p=dtc-xen.git;a=blob;f=src/dtc-xen_finish_install;h=b672bacf201be54ecc18c7af494c084befc4c8ee;hb=b3432d5dbb603e3a14f0fa39df83738627283f65 I'd like to avoid editing the dtc-xen Debconf template if possible, because that means a lot of work for translators. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
