Eggdrop is an IRC robot, that has been around for quite a while. While migrating a Debian box over to Gentoo, I discovered that there was no ebuild script for installing Eggdrop, which I use in a channel on EFnet. This ebuild script works for the latest version, 1.6.13, and cleanly merges, unmerges (with the exception of the user/group and homedir), and upgrades. Post-ebuild, software is installed in: /home/eggdrop and a user/group for eggdrop is created, as eggdrop should _not_ be run as root.
Created attachment 10006 [details] Finished, initial ebuild script for eggdrop-1.6.13
Created attachment 10007 [details] Oops... Ebuild got uploaded as applicaton/octet-stream, got a 400 error.
sorry, no change to get this in
Hmm. Why shouldn't this go in, Martin?
please read bug #10336 bug #4594 and bug #4216 for furter details
hmm well my opinion is that we need to do something about how we add users/groups in ebuilds....I've noticed that this has been a long standing problem that needs some attention. I also personally don't think that we have to not put some things in our tree because they don't conform exactly as we think they should...Eggdrops are very effective tools when used right.
Ok, so I'm just dumb, since I didn't search for _closed_ bugs about this. I agree with _most_ of what Spider had against the original builds, adding a user and putting it in /home seemed the most logical course for _me_, because it really _shouldn't_ be run as root... Yes, if they NFS export /home, that's gonna break. That's a fact of life. So, move the binary to /usr/bin, modules to /usr/lib/eggdrop, and then home just gets config files and scripts: end of story there. Installing eggdrop site-wide, I don't see that as a _problem_, really... Look at eggdrop hosting sites, they don't put an eggdrop binary in _every home directory_ on their site. Yes, I can install eggdrop into my home directory if I want it... but what about site admins who want a dedicated eggdrop server, and that's ALL it's going to be doing, but want portage to be able to update it? My feeling on the matter is that the technical reasons are really just being ignored, and the decision to include it is (mostly) political. YES, eggdrop might open up security holes. So does sendmail, NFS (or anything that uses RPC), NIS Yellow Pages, some FTP daemons, IRC daemons... _BNC_ of all things... I would just like to know what these "too many holes" Spider mentioned are, and then I'll just drop it. I have my ebuild, I'm happy. I just wanted to make lives easier for other Gentoo'ers. Didn't realize it would be such a can of worms.
I agree with both Brad and Curtis here. The only thing that I feel is problematic is that adding a user is probably not an optimal solution.
I definately agree with Brad and Jon about adding users, perhaps it wasn't the best solution for my ebuild, but I couldn't think of anything else that would work... Many ebuilds (mailman, postfix, apache, list goes on) add users in their ebuilds as well, perhaps user management functions should be built into Portage... such as a set of ebuild script commands like: eaddgroup groupname [GID] eadduser username [UID] [groups] That way we don't have to do grep searches on /etc/passwd... and when applications like postfix or apache get unmerged, their users disappear as well, which is _not_ the case right now. Another issue is, we have the capability to emerge applications as a non-root user... maybe there could be an internal USE flag that installs applications like Eggdrop, etc, that are (at least according to Spider) not a good application to have installed site-wide, into the user's ~/ directory. Perhaps, if /home is not the answer to where to put eggdrop, perhaps /opt/eggdrop?
Reopening bug because I feel that this would be something useful to have in the tree.
Is there a decent way to install this system-wide so it can be run as a normal user with configuration/scripts/et al in a user's home directory but the actual eggdrop binary in /usr/bin (or /opt/eggdrop/bin) or something along those lines? That's what I feel would be the optimal solution. Unless there are other objections to that (which would eliminate the eggdrop user issue), an ebuild that does that would be something I'd be interested in adding to the tree.
Putting all of eggdrop's stuff in /opt seems like a good idea... a home directory for eggdrop users could be made, to house bot-specific scripts and configuration files, but put all of the binary stuff in /opt... install a template config file as eggdrop.conf.dist in the /home dir on new installs, which would prevent the issue of config files being overwritten in an upgrade... I don't think it'd be that hard to make a new ebuild that did this, or even to modify mine to do it. To answer a previous comment in one of the aforementioned bugs, Eggdrop works just fine when upgraded within it's minor release (1.6.x, for example), but may have issues if upgraded to 1.7.x, but this is the case with lots of applications.
To answer a previous comment in one of the aforementioned bugs, Eggdrop works just fine when upgraded within it's minor release (1.6.x, for example), but may have issues if upgraded to 1.7.x, but this is the case with lots of applications. Need I remind you of 1.6.4, 1.6.9 ?
I hadn't looked at this bug lately, but had the same conclusion that /opt might be a good place to put this.
Ok, so /opt seems to be the best place for it. In response to Spider's post, my only reply is that in that case, Eggdrop should probably always be in unstable. But that still does not mean it shouldn't be in Portage at all. Let's take a look at all the other packages in Portage that sometimes break when upgraded (I really don't have a list of this but I'm sure there _are_ some), for example. If every package that has a chance of breaking when upgraded was excluded from Portage, there wouldn't be a Portage tree. Eggdrop is an advanced program, for advanced users. Gentoo is an advanced distro. Even if it's only available via ~arch, it's still a valuable addition to Gentoo.
I agree. On that note, if you or someone else posts an ebuild that does all of what's been described above with regards to /opt/eggdrop, configuration in home dirs, that sort of thing, I'd have no problem putting it into the tree.
Created attachment 10668 [details] New ebuild, binaries in /opt, config files/etc in /home/eggdrop This ebuild attempts to cover the comments and agreements made therein regarding placement of files from the Eggdrop package. It (fairly) cleanly merges and unmerges, but it still has the 'eggdrop' user and group. Binaries are in /opt/eggdrop Config files are in /home/eggdrop Some local directories are made in /home/eggdrop to make it easier for users to add local files, so they don't have to do things as root. Needs testing, but should work.
New ebuild up, lemme know if there's things that should be changed, deleted, massaged slightly, etc... I think this fully incorporates what was discussed regarding file placement, etc, but i'm tired and I probably forgot something ^_^
Status update: Sorry about the rather extreme delay, but I was waiting for us to properly implement new user/group additions, which is being worked on now. Hopefully we'll have that in place and I'll be able to commit this ebuild soonish.
Yeah, I forgot something alright, I -just now- noticed that the eggdrop.conf.dist I had made got posted to the wrong bug ^_^; AvenJ, you're working on an ebuild as well? I'm interested to know how the one you're working on compares with mine? I'm relatively new to writing ebuilds so any help or criticism or tips would be appreciated.
Created attachment 13882 [details] eggdrop-1.6.15 ebuild plus goodies OK, I made the mistake of not checking here before going off and creating an ebuild, sooo... I came up with a somewhat new approach to running one or several eggdrops out of /opt/eggdrop, with an /etc/init.d script, automatic crontab installation, modified (config-sensing) botchk, and many many reminders to read the damn manuals and configure thoroughly. I can also boast 99% clean compilation (less an autoconf warning and an uninitialized 't' gripe) without having to mess with any makefiles. It's got a dedicated user - yes, created at install time, i know, i know... - but that should be a good thing. 'eggdrop' owns its vars, logs, and incoming, but 'root' owns the config files and anything else important. Ownership could probably be assigned to a regular user just as easily, so long as it's a member of the 'eggdrop' group. Now, disclaimer: I haven't set up a bot with it. It's 5AM. I'll try that later. I've picked through the install with a fine tooth comb and it /think/ I everything right. No doubt there'll be a follow-up patch.
oops. duh. that 'files/crontick', the EGGDIR= line... that should be '/opt/eggdrop/var', not '/opt/eggdir/var'... that's what I get for hacking through the night...
Created attachment 13961 [details] Working net-irc/eggdrop OK, this one is verified to work ;) Theory hasn't changed, but implementation has significantly. There is now a 'bots.conf' that simply lists the bots that should be started. 'botchk' is now configured via environment variables and no longer requires multiple copies. Also includes patches for the aforementioned configure.in warning and uninitialized 'struct tm *t' lines. Compiles and installs without any warnings or errors at any stage. Files now have copyright headers and internal documentation. A 'README.gentoo' file is supplied to explain how to use all my crap. ;) I haven't actually tried it, but it should be possible to relocate the 'var' and 'log' subdirectories by changing the ebuild and remerging. It won't try to move existing files - you /will/ need to do that, and possibly manually update the /opt/eggdrop/var symlink as well. Oh yeah - '/opt/eggdrop' is also relocatable. This layout was chosen to facilitate multiple bots on a single system, not instant network relocatability. Daemons shouldn't be sensitive to files that can be changed from elsewhere on the network.
Don't mind me, *lurk*. :) I run three eggies and I'm dying for a good solution (Have one in mind, but didn't write up an ebuild for logistical reasons).
Curtis, I had a look at your ebuild and it wasnt bad at all, however it was way more complicated than it had to be for eggdrop. I have taken elements of your ebuild and merged them into my ebuild. Basically I have taken your good ideas and added them to my own into the updated ebuild. I have also included a eggdrop-installer script which basically installs the files needed for eggdrop to run as a normal user. You have to run it as a regular user and basically creates a directory structure like the following: ~/.eggdrop/<bot name>/<eggdrop run time files>. Greg could you have a look at the ebuild and make any neccessary changes to the ebuild so I can be included into the portage tree. Thanks Chuck
Created attachment 15021 [details] Updated Ebuild Updated ebuilded.
Created attachment 15022 [details] Updated Ebuild Updated ebuilded.
Created attachment 15023 [details] Eggdrop installer Eggdrop installer script.
Chuck - --disable-cc-optimizations? I must've missed that one when I was looking through configure the first time... makes my sed-fu seem rather extraneous, doesn't it *sheepish chuckle* in eggdrop-install, since the real issue isn't necessarily root installing, but anyone with a default UID of 0 being root... the $HOME check works, but wouldn't a UID check be better? Just a thought. Other than that... Everyone's work looks good ^_^ I hope we can get eggdrop into portage soon... my eggy's looking kinda outdated.
Eggdrop wont run as root. It will bail on you if you do: bash-2.05b# ./eggdrop Eggdrop v1.6.15 (C) 1997 Robey Pointer (C) 2003 Eggheads [08:02] * ERROR: Eggdrop will not run as root!
I tried the new eggdrop ebuild and installer script today. Works great. I mentioned to zul a few minor changes but he did a great job. Everyone is urged to test this out and leave comments. Thanks!
Created attachment 15046 [details] Updated eggdrop installer Updated eggdrop installer script.
Now in CVS
