*What it is* With Hamachi you can organize two or more computers with an Internet connection into their own virtual network for direct secure communication. Hamachi is fast, secure and simple. It is also free. *What's in it for me* Think - LAN over the Internet. Think - Zero-configuration VPN. Think - Secure peer-to-peer. Access computers remotely. Use Windows File Sharing. Play LAN games. Run private Web or FTP servers. Communicate directly. Stay connected. ----------------------------- Linux version can be found here: http://files.hamachi.cc/linux Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 69304 [details] hamachi-0.9.9.9_beta3.ebuild Suggested ebuild for hamachi.
Created attachment 69305 [details] hamachi.rc Suggested start/stop/init script for hamachi.
Created attachment 69308 [details] hamachi-0.9.9.9_beta3.ebuild Sorry, forgot to add DEPEND on virtual/libc and information message at the end of the ebuild.
1/ The ebuild has de facto hardcoded version - see http://dev.gentoo.org/~ciaranm/docs/mw-faq/hardcoded.txt how to solve this properly. 2/ The virtual/libc DEPEND is redundant, it's implied from system target. 3/ Is RESTRICT="nomirror" really needed here? http://dev.gentoo.org/~ciaranm/docs/mw-faq/nomirror.txt 4/ You can check for necessary kernel features using linux-info eclass.
Created attachment 69336 [details] hamachi-0.9.9.9_beta3.ebuild Jakub, 1) Ok, done. 2) Ok, done. 3) I think it's needed, because of this part on their LICENSE file: "2. ... Except as expressly permitted in this License, the End-User may not decompile, reverse engineer, disassemble, modify, rent, lease, loan, sublicense, distribute or create derivative works based upon the Client in whole or part or transmit the Client over a network ... " However, I'm not a license expert, so I may have missed something. 4) Ok, done.
(In reply to comment #5) > 3) I think it's needed, because of this part on their LICENSE file: Oh OK, thanks for explanation.
I'm not clear about gentoo policy on this, but shouldn't the init script check to see if tun was compiled as a module, and if it is a module and not loaded yet, it should be loaded? Anyways, useful ebuild. Thx
To be fair I don't know if we have a function to test this on init scripts (ideas, anyone?), it could however, test the availability of the device (/dev/tun, if I remember correctly).
Hmm, that'll do. It's /dev/net/tun by the way.
Created attachment 74903 [details] hamachi-0.9.9.9_beta6.ebuild No changes made to the ebuild; I just bumped the version to the latest and tested it.
Is there any time line for this to be put into portage? I have Hamachi up and running using Hamachi's installation instructions because I've had problems with this ebuild.
Created attachment 78467 [details] hamachi-0.9.9.9_beta10.ebuild
Updated to beta10 and modified ebuild to work with new -lnx added onto the hamachi tar.gz
Created attachment 80763 [details] hamachi-0.9.9.9_beta13.ebuild Uploaded Beta 13 of Hamachi Just changed Filename to Beta13
Created attachment 80911 [details] hamachi-0.9.9.9_beta15.ebuild Beta 15 is here ;) Again, just changed File Name.
*** Bug 126856 has been marked as a duplicate of this bug. ***
Beta 16 is here ;)
Created attachment 82846 [details] hamachi-0.9.9.9_beta16.ebuild hamachi-0.9.9.9_beta16.ebuild
Does Anybody know how to rename this ebuild to hamachi-0.9.9.9-16.ebuild ?
Created attachment 83801 [details] Alternate hamachi ebuild I've added al alternate hamachi ebuild script. It create a hamachi user. There are two init scripts (I'll upload them next) that can be used to start tuncfg and hamachi. tuncfg runs as root, hamachi runs as the hamachi user. This should hopefully be more secure and allows you to setup firewall runs based upon uids.
Created attachment 83802 [details] /etc/conf.d/hamchi
Created attachment 83803 [details] files/hamachi.initd
Created attachment 83804 [details] files/hamachi.confd
Created attachment 83805 [details] files/tuncfg.confd
Created attachment 83806 [details] files/tuncfg.initd
Created attachment 83807 [details] hamachi-0.9.9.9_beta17.ebuild (Alt) Beta 17 is out.
Can somebody modify this ebuild to remove the "beta" from the ebuildname? As its an release 17 ... not beta 17 !
Their beta site clearly says "beta releases are now availble for download" at http://www.hamachi.cc/download Thus, this is the 17th beta release. Thus, this is the 17th beta.
I'm not too sure what to do here. The Hamachi forum (http://forums.hamachi.cc/viewtopic.php?t=6467) says "Hamachi/Linux 0.9.9.9-17 is released" but the download page (http://www.hamachi.cc/download) talks about beta releases. I'm not in a position to test changing the name right now so I'll leave it as beta17. I'm not sure that the ebuild I've uploaded includes all of the fixes from previous releases. Can somebody cast their eye over it for me please.
GUI: http://forums.hamachi.cc/viewtopic.php?t=2488
Please note that these files have Windows-style end-of-lines, which causes a lot of problems when being parsed by portage and bash.
I get strange error while trying to digest the ebuild: ---------------------------------------------- # ebuild hamachi-0.9.9.9_beta17.ebuild digest : command not foundnet-p2p/hamachi/hamachi-0.9.9.9_beta17.ebuild: line 4: !!! ERROR: net-p2p/hamachi-0.9.9.9_beta17 failed. Call stack: ebuild.sh, line 1439: Called source '/usr/local/portage/net-p2p/hamachi/hamachi-0.9.9.9_beta17.ebuild' ' hamachi-0.9.9.9_beta17.ebuild, line 5: Called inherit 'eutils' 'linux-info ebuild.sh, line 1174: Called die .eclass could not be found by inherit() !!! If you need support, post the topmost build error, and the call stack if relevant. aux_get(): (0) Error in net-p2p/hamachi-0.9.9.9_beta17 ebuild. (1) Check for syntax error or corruption in the ebuild. (--debug) ---------------------------------------------- Portage 2.1_rc3 Other ebuilds in my personal portage digest well.
Created attachment 90092 [details] hamachi-0.9.9.9_p20 (with much more features!!) Hello! I created a new advanded ebuild! -> hamachi-0.9.9.9_p20 <- This Version has 3 USE flags, gtk for gtk 1.2 gui, gtk2 for gtk2 gui and pentium for an x86 version to work with older cpus! I also added depencies for gtk1 and gtk2 if you are using this gui. I also change the ebuild to create a group called hamachi. I also added ~amd64 keyword. Have fun with this version.
Created attachment 90094 [details] files/hamachi.confd (NEW) /etc/conf.d/hamachi
Created attachment 90095 [details] files/hamachi.initd (NEW) /etc/init.d/hamachi
Created attachment 90097 [details] files/tuncfg.initd (NEW) /etc/init.d/tuncfg
Ah forget to say! I droped /etc/conf.d/tuncfg as it wasn't usefull (just an empty config files without any options!)
In tuncfg.init /usr/sbin/tuncfg should be /sbin/tuncfg. The log directory needed to be created. Other than that this seems to work. It would be nice to have a short note of explanation indicating that the user is supposed to just init start the thing to get going.
I'm not completely sure how to use this setup. I seem to recall seeing some instructions somewhere, but I can't find them there. Setting hamachi so that it starts up with the computer is great, but how am I supposed to specify networks to join and usernames to use?
Created attachment 91069 [details] hamachi-0.9.9.9_p20.ebuild Fixd all bugs written in comment #38
Created attachment 91070 [details] tuncfg.initd Fixed all Bugs written in comment #38
(In reply to comment #41) > Created an attachment (id=91070) [edit] > tuncfg.initd > > Fixed all Bugs written in comment #38 > Looking at the hamachi-0.9.9.9_p20 ebuild, I don't really see any restriction being placed on the hamachi user's permissions. It seems as if the ebuild creates another normal user. Correct me if I'm wrong, but isn't this as much of a security liability as running hamachi as root? Does hamachi really need to run with such extensive priveleges?
Isn't it better not to run anything as root? I thought better to create another user ...
There doesn't appear to be anything that's run as the user hamachi. There are files that owned by hamachi, but not run as hamachi.
(In reply to comment #43) > Isn't it better not to run anything as root? > I thought better to create another user ... > The line in question is this: enewuser ${PN} -1 /bin/bash /home/${PN} ${PN} Perhaps I'm not making myself clear. I agree that it is a good idea to run hamachi through another user rather than root, but this user needs to have very limited permissions. The above command gives the hamachi user shell access and a home directory, which seems a bit excessive It would be better if the line read like this: enewuser ${PN} -1 /bin/false /var/${PN} ${PN} Or something like that. This way, the hamachi user would not have shell access and would have a "home" directory in the var folder like other daemons.
Sorry guys, I goofed. /bin/false is the default value. So, it should look like this: enewuser ${PN} -1 -1 /var/${PN} ${PN}
Created attachment 92499 [details] hamachi-0.9.9.9_p20-r1.ebuild hamachi-0.9.9.9_p20-r1 - I added the changes discussed above. enewuser ${PN} -1 -1 /dev/null ${PN} As far as I can tell, hamachi does not need shell access or a home directory. Hamachi seems to run successfully given these changes.
Created attachment 92501 [details] files/hamachi.initd I changed the following line in the start() function. start-stop-daemon --quiet --start -c ${USER} --exec /usr/bin/hamachi -- $startup I wrapped the hamachi arguments into a variable; for some reason bash was having trouble interpreting all of the arguments and the init script was dieing. This seems to fix that problem.
This bug has become extremely messy. Which * hamachi.confd * tuncfg.initd are people supposed to use?
(In reply to comment #49) > This bug has become extremely messy. Which > > * hamachi.confd > * tuncfg.initd > > are people supposed to use? > You should use the "files/hamachi.confd (NEW)" as it is the only hamachi.confd that is compatible with hamachi-0.9.9.9_p20-r1.ebuild. The older hamachi.confd, posted 2006-04-03 06:03 PST, is obsolete because it does not specify "hamachi" as the hamachi user's group. Also, the two tuncfg.initd files are virtually identical. The second one simply has updated header information "Copyright Gentoo Foundation 1999-2006" as opposed to "1999-2005", so it doesn't matter which one you choose.
Hello! I got a stupid Question. Shouldnt have the Hamachi User an Home Directory? Because Hamachi creates always an ".hamachi" dir ... and if theres no home dir, it is placed in / Or i am wrong?
(In reply to comment #51) > Shouldnt have the Hamachi User an Home Directory? > > Because Hamachi creates always an ".hamachi" dir ... and if theres no home dir, > it is placed in / In this case the .hamachi dir is replaced with /etc/hamachi (see the /etc/conf.d/hamachi file)
Oops ... Didn't saw that! Thx 4 Info.
Yeah, hamachi isn't really built as a system daemon. It actually is supposed to run as a user-level program, but some clever gentoo tricks can make it work as a daemon.
The user needs some directions as to how to use this copy of hamachi. Mainly he needs to be told that .hamachi is now in /etc/hamachi, and to refer to this directory using the appropriate -c arguments. For example, how does a user add a network? It won't run correctly as usual because hamachi will try to access ~/.hamachi instead of /etc/hamachi. If the user skips the /etc/init.d/hamachi and just uses his own it defeats the thinking of having a system-wide installation.
I think it's a bad idea to switch from a user installation to a system wide because: 1) It has questionable maintainability which hinder's it from entering the portage tree 2) It goes against gentoo's policy of following upstream whenever possible 3) Add's confusion to the user. It's difficult recieving help from upstream because their's is different.
(In reply to comment #56) > I think it's a bad idea to switch from a user installation to a system wide > because: > > 1) It has questionable maintainability which hinder's it from entering the > portage tree > > 2) It goes against gentoo's policy of following upstream whenever possible > > 3) Add's confusion to the user. It's difficult recieving help from upstream > because their's is different. > I think this ebuild was created based upon this process: http://forums.hamachi.cc/viewtopic.php?t=3421&start=0 So, system-wide hamachi does seem to be supported upstream. The only difference is that in order to use system-wide hamachi, all hamachi commands have to have the "-c /etc/hamachi" argument. That said, there does not seem to be anything preventing hamachi to be run from the user-level, but system-wide hamachi works with no trouble. I have not found any official documentation other than a "How-To" section on the hamachi message board.
Created attachment 92789 [details] hamachiOverlay.tar.bz2 This hamachi portage overlay should help to clear up the confusion as to what files to download.
Well at the moment this ebuild IS for a system-wide hamachi installation. There are advantages to this. The system's startup process can control the startup of hamachi, and the system-wide hamachi fits well into the paradigm of other system-wide network configuration (IP, routing, dns...) User configuration is not significantly more complicated. From any account the user must only add the -C /etc/hamachi to the normal command. This ebuild could even alias that or something. As for portage, I believe there is plenty of precedent for the system-wide route. Take programs like Freenet which have installed user daemons system-wide.
What about an use flag "user" ? so, it you enable this, the settings are stored in an user account, else system-wide? We could make 2 new confd and initd and use them by switching use flag on.
(In reply to comment #60) > What about an use flag "user" ? > so, it you enable this, the settings are stored in an user account, else > system-wide? > > We could make 2 new confd and initd and use them by switching use flag on. > I really don't see what the difference would be; the system-wide daemon runs under the "hamachi" user anyway. The only difference is that the gentoo init scripts control hamachi, which is IMO much cleaner than running it manually.
As far as I can see the only reason not to use the system-wide option would be to allow different users to run their own instances of hamachi. Is this even possible? What technical implications would that have?
(In reply to comment #62) > As far as I can see the only reason not to use the system-wide option would be > to allow different users to run their own instances of hamachi. Is this even > possible? What technical implications would that have? > I'm not sure how multiple instances of hamachi would work. In order for each instance to have its own IP address, there would have to be multiple /dev/tun devices, which isn't a problem, considering /dev/tun is also used for virtual machine colonies such as User-Mode Linux. However, the real issue is whether hamachi can be made to use a specific virtual NIC. I haven't delved that deep into it, so I don't know if it is even possible.
Created attachment 92831 [details] hamachiOverlay-r1.tar.bz2 !!! Digest verification failed: !!! /usr/local/portage/net-misc/hamachi/files/hamachi.initd !!! Reason: Filesize does not match recorded size !!! Got: 1414 !!! Expected: 1430 ran ebuild hamachi-0.9.9.9_p20-r1.ebuild digest then achieved it
Comment on attachment 92831 [details] hamachiOverlay-r1.tar.bz2 Fixed digest verification failure
So I think we should let is as system-wide ...
(In reply to comment #66) > So I think we should let is as system-wide ... > I agree. It is much safer to let Gentoo handle hamachi, and unless anyone can provide an argument for running hamachi under a user, hamachi should remain as a system-wide daemon.
Created attachment 92929 [details] hamachi-0.9.9.9_p20-r2.ebuild Updated gHamachi GTK 1.2 & GTK 2.0 Version to v0.7.3
Created attachment 92930 [details] hamachi-0.9.9.9_p20-r2.ebuild Updated gHamachi GTK 1.2 & GTK 2.0 Version to v0.7.3
Created attachment 92931 [details] hamachi-0.9.9.9_p20-r2.ebuild Updated gHamachi GTK 1.2 & GTK 2.0 Version to v0.7.3
Well, what about putting this ebuild into portage?
(In reply to comment #71) > Well, what about putting this ebuild into portage? > I guess it would be ok. I have tested it extensively in the past few weeks, and I have had no problems whatsoever.
So Admins, what do you think about it? Put it into Portage?
I'll take ownship and get this one into portage
This guy is now in portage. I made some modifications. First, I split the gui client out into its own ebuild (net-misc/ghamachi) and reworked the use flags. So net-misc hamachi by it self is just the console client. You might want to take a look and make sure there are no glaring errors. Thanks for your work on these ebuilds.
Hi! Thanks, Hamachi is in Portage. But gHamachi is missing?
Sorry, forgot to commit it. It's there now.
I just emereged hamachi, and have problems with tuncfg. I understand there are some portage-limitations here, right? But, what do I, as an end user who knows nothing about ebuilds, do now? localhost arvid # /etc/init.d/hamachi start * Caching service dependencies ... * Service 'fcron' already provided by 'cron'!; * Not adding service 'vixie-cron'... [ ok ] * Starting tuncfg ... tuncfg: cannot stat() /dev/net/tun -- No such file or directory tuncfg: visit http://www.hamachi.cc/tuntap for more information [ !! ] * ERROR: Problem starting needed services. * "hamachi" was not started.
Did you configure tun in your kernel? The ebuild checks for it, but perhaps the check isn't 100% right.
(In reply to comment #79) > Did you configure tun in your kernel? The ebuild checks for it, but perhaps > the check isn't 100% right. > I guess not, but perhaps the ebuild should include some kind of warning which tells you that you have to do that :)
It does - that's my point. I'm guessing you built it as a module, but never modprobed it.
(In reply to comment #81) > It does - that's my point. > > I'm guessing you built it as a module, but never modprobed it. > Well - your guess is right. It's working now
Plus depend is broken, don't use globbing w/ range operators, won't work: <snip> gtk2? ( >=x11-libs/gtk+-2* ) !gtk2? ( =x11-libs/gtk+-1.2* ) </snip> $ emerge -pv \>=x11-libs/gtk+-2* These are the packages that would be merged, in order: Calculating dependencies !!! '>=x11-libs/gtk+-2*' is not a valid package atom. !!! Please check ebuild(5) for full details. !!! (Did you specify a version but forget to prefix with '='?) Plus gtk2 use flag is deprecated and shouldn't be used anywhere (see Bug 106560)
Thanks for the link, Jakub. I couldn't remember the bug#. So what's the solution if there are two supported packages? Should I just drop gtk1 support and force gtk2 without any use flags?
Well yeah, I'd just drop gtk-1 support and all the legacy feeling from ghamachi :) If you really insist, then having two ebuilds would be the best solution here, I guess.
Done.
Btw, we can go ahead and add ~amd64 to the ghamachi keywords; I have tested it and it works.
That requires one of the amd64 folks to do. Cna you open a new bug to request that and assign it to amd64@gentoo.org ? Thanks.
