June 20, 201313 yr I'd like to get the 3 plugins to work together but it seems like there's an issue. Simplefeatures installs version 1.0 of openssh... OpenSSH (and it turns out wget and a few others) are compiled against version .9 A workaround of somesort is to soft link the libssl.so.0 to libssl.so.1...this solves the issue with wget...but when I try and start the ssh daemon or generate a key I get the following error: OpenSSL version mismatch. Built against 9080ef, you have 1000103f Is there someway to make the .9 and the 1.0 versions co-exist? Is there a package (plugin) for sshd compiled with version 1.0? (Or statically linked?) Thanks, Ron Conti
June 20, 201313 yr Without recompiling you could 'possibly' install the older openssl libraries to a new directory. Then use export LD_LIBRARY_PATH= to the openssl libraries you want to access. but that's quite cumbersome. I've had to do this a number of times with CURL programs. Especially on Solaris. LD_LIBRARY_PATH=/usr/local/lib/(somedirectory) /usr/local/bin/curl (arguments).
June 20, 201313 yr I'd like to get the 3 plugins to work together but it seems like there's an issue. Simplefeatures installs version 1.0 of openssh... OpenSSH (and it turns out wget and a few others) are compiled against version .9 A workaround of somesort is to soft link the libssl.so.0 to libssl.so.1...this solves the issue with wget...but when I try and start the ssh daemon or generate a key I get the following error: OpenSSL version mismatch. Built against 9080ef, you have 1000103f Is there someway to make the .9 and the 1.0 versions co-exist? Is there a package (plugin) for sshd compiled with version 1.0? (Or statically linked?) Thanks, Ron Conti Out of interest, which plugins under the more general heading of 'SimpleFeatures' are you using? To my knowledge there's no plugin provided by SimpleFeatures that uses OpenSSH. Only OpenSSL. Conversely, my OpenSSH plugin only installs OpenSSH. There is no dependency on an OpenSSL package. The following SimpleFeatures plugins appear co-exist with OpenSSH plugin (openssh_overbyrn.plg, v1.3) ... simpleFeatures.active.streams-1.0.10-noarch-1.plg simpleFeatures.activity.monitor-1.0.11-noarch-1.plg simpleFeatures.cache.dirs-1.0.11-noarch-1.plg simpleFeatures.core.webGUI-1.0.11-noarch-1.plg simpleFeatures.disk.health-1.0.11-noarch-1.plg simpleFeatures.disk.preclear-1.0.10-noarch-1.plg simpleFeatures.email.notify-1.0.10-noarch-1.plg simpleFeatures.log.viewer-1.0.10-noarch-1.plg simpleFeatures.s3.sleep-1.0.10-noarch-1.plg simpleFeatures.system.info-1.0.10-noarch-1.plg simpleFeatures.system.stats-1.0.10-noarch-1.plg simpleFeatures.system.temp-1.0.11-noarch-1.plg Regards, overbyrn
June 20, 201313 yr Author I'm using: simpleFeatures.active.streams-1.0.10-noarch-1.plg* simpleFeatures.activity.monitor-1.0.11-noarch-1.plg* simpleFeatures.cache.dirs-1.0.11-noarch-1.plg* simpleFeatures.core.webGUI-1.0.11-noarch-1.plg* simpleFeatures.disk.health-1.0.11-noarch-1.plg* simpleFeatures.disk.preclear-1.0.10-noarch-1.plg* simpleFeatures.email.notify-1.0.10-noarch-1.plg* simpleFeatures.itunes.server-1.0.11-noarch-1.plg* simpleFeatures.log.viewer-1.0.10-noarch-1.plg* simpleFeatures.s3.sleep-1.0.10-noarch-1.plg* simpleFeatures.system.info-1.0.10-noarch-1.plg* simpleFeatures.system.stats-1.0.10-noarch-1.plg* simpleFeatures.system.temp-1.0.11-noarch-1.plg*
June 20, 201313 yr Are the keys generated by openssh regenerated every boot with the plugin? (Which would result in an untrusted message upon reconnection every reboot). If not you could always generate your key using openssh, (without SF installed), and then reboot, ensure you can connect, and then install SF.
June 20, 201313 yr Are the keys generated by openssh regenerated every boot with the plugin? (Which would result in an untrusted message upon reconnection every reboot). If not you could always generate your key using openssh, (without SF installed), and then reboot, ensure you can connect, and then install SF. It's a one time key generation. They are stored in the plugin directory and copied over upon a reboot so untrusted messages should never appear unless the user specifically removes them causing the plugin to generate new ones.
June 20, 201313 yr Are the keys generated by openssh regenerated every boot with the plugin? (Which would result in an untrusted message upon reconnection every reboot). If not you could always generate your key using openssh, (without SF installed), and then reboot, ensure you can connect, and then install SF. It's a one time key generation. They are stored in the plugin directory and copied over upon a reboot so untrusted messages should never appear unless the user specifically removes them causing the plugin to generate new ones. if the openssh daemon does not require the openssl libraries, you might be able to limp by. you can installpkg the older libssl to another directory or even over what you have. run the ssh-keygen. save the keys. reboot. manually put the keys in place. run openssh.
June 20, 201313 yr Author How can I tell which simplefeatures plugins use openssl? Maybe i can just not use that plugin?
June 20, 201313 yr How can I tell which simplefeatures plugins use openssl? Maybe i can just not use that plugin? Ask the author, I have no idea, I don't use simple features. maybe look at the .plg files?
June 20, 201313 yr How can I tell which simplefeatures plugins use openssl? Maybe i can just not use that plugin? Email notify probably does Sent from a phone, sorry for any typos
June 20, 201313 yr How can I tell which simplefeatures plugins use openssl? Maybe i can just not use that plugin? Email notify probably does Sent from a phone, sorry for any typos Three plugins by SimpleFeatures calls for OpenSSL; Email Notify Web Server iTunes Server None use OpenSSH. But I think you need to take a step back and perhaps clarify exactly what plugins (inc. versions) you are using. I've already said that OpenSSH plugin as it is in its current version has no problem with SimpleFeatures. So to be honest I am struggling to understand why you are seeing this error. Can you elaborate on exactly what plugins and other non-native UnRAID code you are running?
June 20, 201313 yr Author I like some of the features of 'simplefeatures'; esp. the email notification... I'd also like to get crashplan running...to get crashplan running, you need openssh.
June 20, 201313 yr I like some of the features of 'simplefeatures'; esp. the email notification... I'd also like to get crashplan running...to get crashplan running, you need openssh. I'm sorry, I can't help further unless you can give me more information as requested in my previous post.
June 20, 201313 yr I think the ssh-keygen program might be having issues. Maybe ssh-keygen itself or a library it uses requires some function from the openssl library. If it's just that binary, you can make the keys anywhere. Or install the libraries needed, make the keys, save them. Then reboot. install all your modules and restore the keys. I'm guessing really, since I'm not using either.
June 20, 201313 yr OpenSSH may refuse to create keys if the libraries don't agree with the version running. This could be done to prevent generation of compromised or insecure keys .
June 20, 201313 yr The latest OpenSSH requires openssl 1.0 libraries, why not use the latest version? There is a pre-compiled Openssh slackware package on pkgs.org. This is the problem with unRAID/Slackware not having a unified package manager. apt-get/yum would be very useful right about now......
June 21, 201313 yr Author I did a quick 'find' for all the txz files in /boot....I think that's what you were asking for... here's the list: root@Tower:/boot# find . -name '*.txz' ./config/plugins/ssh/putty-0.62-i486-1rj.txz ./packages/openssh-5.8p1-i486-1.txz ./packages/openssl-0.9.8r-i486-3.txz ./packages/cpio-2.11-i486-1.txz ./packages/openssl-1.0.1c-i486-3.txz ./packages/openssh-5.9p1-i486-2_slack13.37.txz ./packages/alsa-lib-1.0.26-i486-1.txz ./packages/celt-0.11.1-i486-1sl.txz ./packages/confuse-2.7-i486-1sl.txz ./packages/dirac-1.0.2-i486-5sl.txz ./packages/expat-2.0.1-i486-2.txz ./packages/faac-1.28-i486-5sl.txz ./packages/faad2-2.7-i486-7sl.txz ./packages/ffmpeg-0.10.6-i486-1gds.txz ./packages/fftw-3.2.2-i486-1.txz ./packages/flac-1.2.1-i486-3.txz ./packages/gdbm-1.8.3-i486-4.txz ./packages/gsm-1.0.13-i486-2gds.txz ./packages/lame-3.99.5-i686-1cf.txz ./packages/libaacplus-2.0.2-i486-1sl.txz ./packages/libavl-0.3.5-i686-1_SBo.txz ./packages/libdaemon-0.14-i486-2sl.txz ./packages/libevent-2.0.19-i686-2cf.txz ./packages/libgcrypt-1.5.0-i486-1.txz ./packages/libgpg-error-1.10-i486-1.txz ./packages/libogg-1.3.0-i486-1.txz ./packages/libplist-1.4-i486-1.txz ./packages/libtheora-1.1.1-i486-1.txz ./packages/libunistring-0.9.3-i486-1sl.txz ./packages/libva-1.0.16-i486-1gds.txz ./packages/libvorbis-1.3.2-i486-1.txz ./packages/libvpx-1.1.0-i686-1gds.txz ./packages/libX11-1.5.0-i486-1.txz ./packages/libXau-1.0.7-i486-1.txz ./packages/libxcb-1.8.1-i486-1.txz ./packages/libXdmcp-1.1.1-i486-1.txz ./packages/mxml-2.6-i486-5sl.txz ./packages/opencore-amr-0.1.3-i486-5sl.txz ./packages/openjpeg-20110623-i486-1sl.txz ./packages/openssl-solibs-1.0.1c-i486-3.txz ./packages/orc-0.4.16-i486-2gds.txz ./packages/rtmpdump-2.4.20120901-i486-1gds.txz ./packages/schroedinger-1.0.11-i486-1sl.txz ./packages/speex-1.2rc1-i486-7sl.txz ./packages/taglib-1.7.2-i486-1.txz ./packages/x264-20120830-i486-1gds.txz ./packages/xvidcore-1.3.2-i486-3sl.txz ./packages/zlib-1.2.6-i486-1.txz ./plugins/simpleFeatures/simpleFeatures.active.streams-1.0.10-i486-1.txz ./plugins/simpleFeatures/simpleFeatures.activity.monitor-1.0.11-i486-1.txz ./plugins/simpleFeatures/simpleFeatures.cache.dirs-1.0.11-i486-1.txz ./plugins/simpleFeatures/simpleFeatures.core.webGUI-1.0.11-i486-1.txz ./plugins/simpleFeatures/simpleFeatures.disk.health-1.0.11-i486-1.txz ./plugins/simpleFeatures/simpleFeatures.email.notify-1.0.10-i486-1.txz ./plugins/simpleFeatures/simpleFeatures.system.stats-1.0.10-i486-1.txz ./plugins/simpleFeatures/simpleFeatures.system.temp-1.0.11-i486-1.txz ./plugins/simpleFeatures/simpleFeatures.itunes.server-1.0.11-i486-1.txz ./plugins/simpleFeatures/simpleFeatures.log.viewer-1.0.10-i486-1.txz ./plugins/simpleFeatures/simpleFeatures.s3.sleep-1.0.10-i486-1.txz ./plugins/simpleFeatures/simpleFeatures.system.info-1.0.10-i486-1.txz I also have unmenu installed..
June 21, 201313 yr The latest OpenSSH requires openssl 1.0 libraries, why not use the latest version? There is a pre-compiled Openssh slackware package on pkgs.org. This is the problem with unRAID/Slackware not having a unified package manager. apt-get/yum would be very useful right about now...... I recall trying a version of OpenSSH v1.0 in my plugin. As you say, OpenSSH 1.0 now requires OpenSSL 1.0. At the time of testing I hit issues with earlier beta versions of UnRAID 5.x due to incompatible libs. I have a vague memory that I didn't need to install the main OpenSSL 1.0 package to get OpenSSH 1.0 working, but rather openssl-solibs. But that configuration was causing segfaults with GLIBC. So I played safe and left things with a version of OpenSSH that didn't call for OpenSSL libs and thus didn't have a GLIBC incompatibility.
June 21, 201313 yr The latest OpenSSH requires openssl 1.0 libraries, why not use the latest version? There is a pre-compiled Openssh slackware package on pkgs.org. This is the problem with unRAID/Slackware not having a unified package manager. apt-get/yum would be very useful right about now...... Perhaps something like slapt-get (http://software.jaos.org/) could be useful for managing packages with regard to plugins. I've had a little play around with it and it seems to work ok on unraid. There would be 1 or 2 things to be thought about before it could be adopted as part of unraid though. First being the location where it stores it's cache (downloaded packages, details of sources etc), by default this is in /var and for unraid it probably ought to be on the flash in /boot. Changing that location is just a tweak of a config file, but when I tried changing that and then moving the cache from /var I encountered problems relating to the names of some of the files in the cache. It uses the url to a package source as a file name, while it replaces/escapes some invalid characters it leaves colons in, which aren't valid on a fat32 flash drive. So a small tweak to the source would be needed. Some thought would probably also need to go into the location of the config file. By default it's in /etc/slapt-get, but again it ought to be somewhere which is persistent and user editable. So that users can add/change package sources etc. I'd envisage that slapt-get would be included as part of unraid, and that during boot unraid would check for and create if necessary the folder on the flash to use as the cache and setup the default config file - if it doesn't already exist. Plugins could then be adapted to include a dependency section which specified which packages the plugin requires to be installed by slapt-get. Anybody got any thoughts?
June 21, 201313 yr The latest OpenSSH requires openssl 1.0 libraries, why not use the latest version? There is a pre-compiled Openssh slackware package on pkgs.org. This is the problem with unRAID/Slackware not having a unified package manager. apt-get/yum would be very useful right about now...... Perhaps something like slapt-get (http://software.jaos.org/) could be useful for managing packages with regard to plugins. I've had a little play around with it and it seems to work ok on unraid. There would be 1 or 2 things to be thought about before it could be adopted as part of unraid though. First being the location where it stores it's cache (downloaded packages, details of sources etc), by default this is in /var and for unraid it probably ought to be on the flash in /boot. Changing that location is just a tweak of a config file, but when I tried changing that and then moving the cache from /var I encountered problems relating to the names of some of the files in the cache. It uses the url to a package source as a file name, while it replaces/escapes some invalid characters it leaves colons in, which aren't valid on a fat32 flash drive. So a small tweak to the source would be needed. Some thought would probably also need to go into the location of the config file. By default it's in /etc/slapt-get, but again it ought to be somewhere which is persistent and user editable. So that users can add/change package sources etc. I'd envisage that slapt-get would be included as part of unraid, and that during boot unraid would check for and create if necessary the folder on the flash to use as the cache and setup the default config file - if it doesn't already exist. Plugins could then be adapted to include a dependency section which specified which packages the plugin requires to be installed by slapt-get. Anybody got any thoughts? butlerpeter, I would suggest you copy your post and start a new thread so there would be more discussion on it, it's a good idea. I bet A community wide discussion would blossom into something if it were a separate thread. it might get list being discussed within this one.
June 21, 201313 yr butlerpeter, I would suggest you copy your post and start a new thread so there would be more discussion on it, it's a good idea. I bet A community wide discussion would blossom into something if it were a separate thread. it might get list being discussed within this one. Done http://lime-technology.com/forum/index.php?topic=28140.0
Archived
This topic is now archived and is closed to further replies.