Re: [DNG] Python modules SimpleHTTPServer / SocketServer
On Sun, 12 Aug 2018 19:53:43 +0200 Evilham wrote: [snip] > This may be the place you reached: this now runs a web server, > leave this command running. Thanks! That's the bit that counts... [snip] > 4. Edit lib/debian-releases.mk accordingly > 5. Check if it works with devuan config, basically repeat 2. It does. [snip] > Also notice that if you want, you can just git clone my repository and > follow 2. (the commands do take "forever" :-D so do that if you trust > what I did, which maybe you should not as you may have read more about > this!). Reading is one thing, knowing what you're doing is another... > > Another interesting thing is that in 2.d I used /oldstable to test, > since that was "jessie" in both Debian and Devuan, /stable returns no > entries (which is wrong!) it may have something to do with > /data/config.json or sth like that, I'll leave that for your further > testing I've managed to get some of these pages filled with data. >(you have write permissions to that repo, so please update > that if you make progress). I have cloned it, and made a few commits. The devuan version looks devuanized: although there are some empty pages, some of them appear to be where they should be e.g. bugs for ascii-backports. > If we are going to use this, we want to merge back to Debian's repo as > much as possible to minimise long-term maintenance overhead; that > means some refactoring because, of course, this is built with a very > specific Debian-only mindset. > Ideally running this ends up being a matter of cloning upstream, > adding a config file or (some) env var(s) and that's it, i.e.: no > fiddling with Makefiles and the likes. I'd be happy to do what I can. > That may prove to be unrealistic since along with the software, there > is a bunch of data in the same repository and their workflow appears > to take advantage of that. I am certain you will know better than > me :-). > > If you need any more help, just reply (but make sure you CC me :-D). Many Thanks. Please let me know what next steps would be most helpful towards turning this into a useful tool. Perhaps the question that is uppermost in my mind is how to verify that the new database contains the correct combinations of packages, bugs and patches, i.e. is it trustworthy. Thanks again for your most helpful advice. leloft ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Cannot install wine32 on ASCII.
On Mon, Aug 13, 2018 at 06:42:07PM +0200, Evilham wrote:
> Am 13.08.2018 um 18:39 schrieb Edward Bartolo:
> > On 13/08/2018, info at smallinnovations dot nl
> > wrote:
> > [...]
> >>
> >> I suspect your system is not multiarch atm. You can add i386 with the
> >> command
> >>
> >> dpkg --add-architecture i386
> >>
> >
> > I have already added the i386 architecture. This is what dpkg tells me:
> >
> > dpkg --print-foreign-architectures
> > i386
>
> Hum, simultaneous posting. Make sure you ran apt-get update and that the
> apt install command looks like on the wiki in Step 2 (notice that it
> references both libwine and libwine:i386 and also wine{,32,64}).
>
> If that still doesn't work, please post what I asked you in the other email.
Random guess: which repo are you using? If you are still using
packages.devuan.org or *.mirror.devuan.org, then you should switch to
deb.devuan.org, since we know of existing glitches with ascii in the
original amprolla.
HND
KatolaZ
--
[ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ]
[ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ]
[ @) http://kalos.mine.nu --- Devuan GNU + Linux User ]
[ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ]
[ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ]
signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Cannot install wine32 on ASCII.
Am 13.08.2018 um 18:39 schrieb Edward Bartolo:
> On 13/08/2018, info at smallinnovations dot nl
> wrote:
> [...]
>>
>> I suspect your system is not multiarch atm. You can add i386 with the
>> command
>>
>> dpkg --add-architecture i386
>>
>
> I have already added the i386 architecture. This is what dpkg tells me:
>
> dpkg --print-foreign-architectures
> i386
Hum, simultaneous posting. Make sure you ran apt-get update and that the
apt install command looks like on the wiki in Step 2 (notice that it
references both libwine and libwine:i386 and also wine{,32,64}).
If that still doesn't work, please post what I asked you in the other email.
--
Evilham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Cannot install wine32 on ASCII.
Am 13.08.2018 um 15:58 schrieb Edward Bartolo:
> You write like someone wanting to hit me. Well, I am on Blessed Devuan
> ASCII and my system is refusing to install wine32 because of missing
> libraries it cannot resolve. So, it is Devuan at blame.
Sorry if you read that, I just hoped instead of spending 20 minutes
writing a full-blown email, I'd ask if you had checked that. Because
wine is actually a bit of a special package and requires some reading.
TBF, it is not *Devuan* "at blame" (which you hint at since first
email), it is the way wine is packaged in Debian, which for technical
reasons is a bit special on 64bit systems.
(if interested, apt-get install wine only allows you to run 64bit
binaries, because pulling wine32 somewhat "pollutes" your system with
32bit libraries which is not desirable in a general use-case, so it *is*
doable, it is just not a very trivial thing)
You will have the exact same issues on any Debian-derivative (quick
online search shows bug reports for Ubuntu and Debian too), that's what
I meant with "nothing Devuan-specific"; it's just a bit odd.
As "smallinnovations" wrote, it sounds like you are not multiarch, which
is why I pointed to the wiki article [1] which is quite complete
("smallinnovations" recommendation is Step 1 over there).
If it is still not working after following *all steps* listed for Jessie
and newer *and* reading on Multiarch [2] under Debian-based systems it
is still not working, we need more than just apt error messages and
*maybe* we will be able to *help* you, you know, voluntarily:
1. dpkg --print-architechture
2. dpkg --print-foreign-architectures
3. list of enabled repositories (+ architechture)
4. dpkg -l | grep wine
The articles you should read:
[1]: https://wiki.debian.org/Wine
[2]: https://wiki.debian.org/Multiarch/HOWTO
For what it's worth, I just followed the steps on the wiki myself and it
works flawlessly.
Most likely you really just need to check your enabled repositories and
run Steps 1 and 2 from the Wine article [1].
--
Evilham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] [OT] Cannot install wine32 on ASCII.
On 13/08/2018, info at smallinnovations dot nl wrote: [...] > > I suspect your system is not multiarch atm. You can add i386 with the > command > > dpkg --add-architecture i386 > I have already added the i386 architecture. This is what dpkg tells me: dpkg --print-foreign-architectures i386 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Cannot install wine32 on ASCII.
On 13-08-18 15:58, Edward Bartolo wrote: > On 13/08/2018, Evilham wrote: > 08.2018 um 14:30 schrieb Edward Bartolo: >>> apt-get laments: > [...] >>> Can I continue using Devuan ASCII and have wine32? >> None of that is Devuan-specific. Have you read this? >> >> https://wiki.debian.org/Wine >> -- >> Evilham >> > OK, so I RTFM irrespective of knowing that will not help. This is what > my ASCII system complains about running the first command from the > site: > > > # apt-get install wine wine32 wine64 libwine libwine:i386 fonts-wine > Reading package lists... Done > Building dependency tree > Reading state information... Done > fonts-wine is already the newest version (1.8.7-2). > fonts-wine set to manually installed. > libwine is already the newest version (1.8.7-2). > wine is already the newest version (1.8.7-2). > wine64 is already the newest version (1.8.7-2). > wine64 set to manually installed. > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > libwine:i386 : Depends: libfontconfig1:i386 (>= 2.11) but it is not > going to be installed > Depends: libfreetype6:i386 (>= 2.2.1) but it is not > going to be installed > Depends: libldap-2.4-2:i386 (>= 2.4.7) but it is not > going to be installed > Depends: libmpg123-0:i386 (>= 1.13.7) but it is not > going to be installed > Recommends: libcups2:i386 (>= 1.4.0) but it is not > going to be installed > Recommends: libgnutls30:i386 (>= 3.5.0) but it is not > going to be installed > Recommends: libpng16-16:i386 (>= 1.6.2-1) but it is > not going to be installed > Recommends: libasound2-plugins:i386 but it is not > going to be installed > E: Unable to correct problems, you have held broken packages. > - > > You write like someone wanting to hit me. Well, I am on Blessed Devuan > ASCII and my system is refusing to install wine32 because of missing > libraries it cannot resolve. So, it is Devuan at blame. > > Please, no puerile flamewars. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng I suspect your system is not multiarch atm. You can add i386 with the command dpkg --add-architecture i386 Grtz Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] [OT] Cannot install wine32 on ASCII.
On 13/08/2018, Evilham wrote: 08.2018 um 14:30 schrieb Edward Bartolo: >> apt-get laments: [...] >> Can I continue using Devuan ASCII and have wine32? > > None of that is Devuan-specific. Have you read this? > > https://wiki.debian.org/Wine > -- > Evilham > OK, so I RTFM irrespective of knowing that will not help. This is what my ASCII system complains about running the first command from the site: # apt-get install wine wine32 wine64 libwine libwine:i386 fonts-wine Reading package lists... Done Building dependency tree Reading state information... Done fonts-wine is already the newest version (1.8.7-2). fonts-wine set to manually installed. libwine is already the newest version (1.8.7-2). wine is already the newest version (1.8.7-2). wine64 is already the newest version (1.8.7-2). wine64 set to manually installed. Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libwine:i386 : Depends: libfontconfig1:i386 (>= 2.11) but it is not going to be installed Depends: libfreetype6:i386 (>= 2.2.1) but it is not going to be installed Depends: libldap-2.4-2:i386 (>= 2.4.7) but it is not going to be installed Depends: libmpg123-0:i386 (>= 1.13.7) but it is not going to be installed Recommends: libcups2:i386 (>= 1.4.0) but it is not going to be installed Recommends: libgnutls30:i386 (>= 3.5.0) but it is not going to be installed Recommends: libpng16-16:i386 (>= 1.6.2-1) but it is not going to be installed Recommends: libasound2-plugins:i386 but it is not going to be installed E: Unable to correct problems, you have held broken packages. - You write like someone wanting to hit me. Well, I am on Blessed Devuan ASCII and my system is refusing to install wine32 because of missing libraries it cannot resolve. So, it is Devuan at blame. Please, no puerile flamewars. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Cannot install wine32 on ASCII.
Am 13.08.2018 um 14:30 schrieb Edward Bartolo:
> apt-get laments:
>
> # apt-get install wine32
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
> wine32:i386 : Depends: libwine:i386 (= 1.8.7-2) but it is not going
> to be installed
> E: Unable to correct problems, you have held broken packages.
>
> Aptitude whines far longer but still nothing convincing apart from a
> hair raising suggestion:
>
> # aptitude install wine32
> Note: selecting "wine32:i386" instead of the virtual package "wine32"
> The following NEW packages will be installed:
> gcc-6-base:i386{a} i965-va-driver:i386{a} libasound2:i386{a}
> libasound2-plugins:i386{a}
> libasyncns0:i386{a} libavahi-client3:i386{a} libavahi-common-data:i386{a}
> libavahi-common3:i386{a} libavcodec57:i386{a} libavresample3:i386{a}
> libavutil55:i386{a}
> libbsd0:i386{a} libc6:i386{a} libcairo2:i386{a} libcap2:i386{a}
> libcomerr2:i386{a}
> libcrystalhd3:i386{a} libcups2:i386{ab} libdb5.3:i386{a} libdbus-1-3:i386{a}
> libdrm-amdgpu1:i386{a} libdrm-intel1:i386{a} libdrm-nouveau2:i386{a}
> libdrm-radeon1:i386{a}
> libdrm2:i386{a} libedit2:i386{a} libelf1:i386{a} libexpat1:i386{a}
> libffi6:i386{a}
> libflac8:i386{a} libfontconfig1:i386{a} libfreetype6:i386{a}
> libgcc1:i386{a} libgcrypt20:i386{a}
> libgl1-mesa-dri:i386{a} libgl1-mesa-glx:i386{a}
> libglapi-mesa:i386{a} libglu1-mesa:i386{a}
> libgmp10:i386{a} libgnutls30:i386{a} libgomp1:i386{a}
> libgpg-error0:i386{a} libgpm2:i386{a}
> libgsm1:i386{a} libgssapi-krb5-2:i386{a} libhogweed4:i386{a}
> libice6:i386{a} libicu57:i386{a}
> libidn11:i386{a} libjack-jackd2-0:i386{a} libjbig0:i386{a}
> libjpeg62-turbo:i386{a}
> libk5crypto3:i386{a} libkeyutils1:i386{a} libkrb5-3:i386{a}
> libkrb5support0:i386{a}
> liblcms2-2:i386{a} libldap-2.4-2:i386{a} libllvm3.9:i386{a}
> libltdl7:i386{a} liblz4-1:i386{a}
> liblzma5:i386{a} libmp3lame0:i386{a} libmpg123-0:i386{ab}
> libncurses5:i386{a} libnettle6:i386{a}
> libnuma1:i386{a} libodbc1:i386{a} libogg0:i386{a} libopenal1:i386{a}
> libopenjp2-7:i386{a}
> libopus0:i386{a} libosmesa6:i386{a} libp11-kit0:i386{ab}
> libpcap0.8:i386{a} libpciaccess0:i386{a}
> libpcre3:i386{a} libpixman-1-0:i386{a} libpng16-16:i386{ab}
> libpulse0:i386{a}
> libsamplerate0:i386{a} libsasl2-2:i386{a} libsasl2-modules:i386{a}
> libsasl2-modules-db:i386{a}
> libselinux1:i386{a} libsensors4:i386{a} libshine3:i386{a}
> libsm6:i386{a} libsnappy1v5:i386{a}
> libsndfile1:i386{a} libsndio6.1:i386{a} libsoxr0:i386{a}
> libspeex1:i386{a} libspeexdsp1:i386{a}
> libssl1.1:i386{a} libstdc++6:i386{a} libswresample2:i386{a}
> libsystemd0:i386{a}
> libtasn1-6:i386{ab} libtheora0:i386{a} libtiff5:i386{a}
> libtinfo5:i386{a} libtwolame0:i386{a}
> libtxc-dxtn-s2tc:i386{ab} libuuid1:i386{a} libva-drm1:i386{a}
> libva-x11-1:i386{a} libva1:i386{a}
> libvdpau-va-gl1:i386{a} libvdpau1:i386{a} libvorbis0a:i386{a}
> libvorbisenc2:i386{a}
> libvpx4:i386{a} libwavpack1:i386{ab} libwebp6:i386{a}
> libwebpmux2:i386{a} libwine:i386{a}
> libwrap0:i386{a} libx11-6:i386{a} libx11-xcb1:i386{a}
> libx264-148:i386{a} libx265-95:i386{a}
> libxau6:i386{a} libxcb-dri2-0:i386{a} libxcb-dri3-0:i386{a}
> libxcb-glx0:i386{a}
> libxcb-present0:i386{a} libxcb-render0:i386{a} libxcb-shm0:i386{a}
> libxcb-sync1:i386{a}
> libxcb1:i386{a} libxcomposite1:i386{a} libxcursor1:i386{a}
> libxdamage1:i386{a} libxdmcp6:i386{a}
> libxext6:i386{a} libxfixes3:i386{a} libxi6:i386{a}
> libxinerama1:i386{a} libxml2:i386{a}
> libxrandr2:i386{a} libxrender1:i386{a} libxshmfence1:i386{a}
> libxslt1.1:i386{a} libxtst6:i386{a}
> libxvidcore4:i386{a} libxxf86vm1:i386{a} libzvbi0:i386{a}
> mesa-va-drivers:i386{a}
> mesa-vdpau-drivers:i386{a} ocl-icd-libopencl1:i386{a}
> uuid-runtime{a} va-driver-all:i386{a}
> vdpau-driver-all:i386{a} wine32:i386 zlib1g:i386{a}
> 0 packages upgraded, 156 newly installed, 0 to remove and 20 not upgraded.
> Need to get 81.0 MB of archives. After unpacking 483 MB will be used.
> The following packages have unmet dependencies:
> libcups2 : Breaks: libcups2:i386 (!= 2.2.3-2) but 2.2.1-8+deb9u2 is
> to be installed
> libcups2:i386 : Breaks: libcups2 (!= 2.2.1-8+deb9u2) but 2.2.3-2 is installed
> libtxc-dxtn-s2tc:i386 : Conflicts: libtxc-dxtn0 which is a virtual
> package, provided by:
> - libtxc-dxtn-s2tc0
> (0~git20131104-1.1), but 0~git20131104-1.1 is installed
> - libtxc-dxtn-s2tc
> (1.0+git20151227-2), but it is not going to be installed
>
> libtxc-dxtn-s2tc0 : Conflicts: libtxc-dxtn0:i386 which is a
[DNG] [OT] Cannot install wine32 on ASCII.
apt-get laments:
# apt-get install wine32
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
wine32:i386 : Depends: libwine:i386 (= 1.8.7-2) but it is not going
to be installed
E: Unable to correct problems, you have held broken packages.
Aptitude whines far longer but still nothing convincing apart from a
hair raising suggestion:
# aptitude install wine32
Note: selecting "wine32:i386" instead of the virtual package "wine32"
The following NEW packages will be installed:
gcc-6-base:i386{a} i965-va-driver:i386{a} libasound2:i386{a}
libasound2-plugins:i386{a}
libasyncns0:i386{a} libavahi-client3:i386{a} libavahi-common-data:i386{a}
libavahi-common3:i386{a} libavcodec57:i386{a} libavresample3:i386{a}
libavutil55:i386{a}
libbsd0:i386{a} libc6:i386{a} libcairo2:i386{a} libcap2:i386{a}
libcomerr2:i386{a}
libcrystalhd3:i386{a} libcups2:i386{ab} libdb5.3:i386{a} libdbus-1-3:i386{a}
libdrm-amdgpu1:i386{a} libdrm-intel1:i386{a} libdrm-nouveau2:i386{a}
libdrm-radeon1:i386{a}
libdrm2:i386{a} libedit2:i386{a} libelf1:i386{a} libexpat1:i386{a}
libffi6:i386{a}
libflac8:i386{a} libfontconfig1:i386{a} libfreetype6:i386{a}
libgcc1:i386{a} libgcrypt20:i386{a}
libgl1-mesa-dri:i386{a} libgl1-mesa-glx:i386{a}
libglapi-mesa:i386{a} libglu1-mesa:i386{a}
libgmp10:i386{a} libgnutls30:i386{a} libgomp1:i386{a}
libgpg-error0:i386{a} libgpm2:i386{a}
libgsm1:i386{a} libgssapi-krb5-2:i386{a} libhogweed4:i386{a}
libice6:i386{a} libicu57:i386{a}
libidn11:i386{a} libjack-jackd2-0:i386{a} libjbig0:i386{a}
libjpeg62-turbo:i386{a}
libk5crypto3:i386{a} libkeyutils1:i386{a} libkrb5-3:i386{a}
libkrb5support0:i386{a}
liblcms2-2:i386{a} libldap-2.4-2:i386{a} libllvm3.9:i386{a}
libltdl7:i386{a} liblz4-1:i386{a}
liblzma5:i386{a} libmp3lame0:i386{a} libmpg123-0:i386{ab}
libncurses5:i386{a} libnettle6:i386{a}
libnuma1:i386{a} libodbc1:i386{a} libogg0:i386{a} libopenal1:i386{a}
libopenjp2-7:i386{a}
libopus0:i386{a} libosmesa6:i386{a} libp11-kit0:i386{ab}
libpcap0.8:i386{a} libpciaccess0:i386{a}
libpcre3:i386{a} libpixman-1-0:i386{a} libpng16-16:i386{ab} libpulse0:i386{a}
libsamplerate0:i386{a} libsasl2-2:i386{a} libsasl2-modules:i386{a}
libsasl2-modules-db:i386{a}
libselinux1:i386{a} libsensors4:i386{a} libshine3:i386{a}
libsm6:i386{a} libsnappy1v5:i386{a}
libsndfile1:i386{a} libsndio6.1:i386{a} libsoxr0:i386{a}
libspeex1:i386{a} libspeexdsp1:i386{a}
libssl1.1:i386{a} libstdc++6:i386{a} libswresample2:i386{a}
libsystemd0:i386{a}
libtasn1-6:i386{ab} libtheora0:i386{a} libtiff5:i386{a}
libtinfo5:i386{a} libtwolame0:i386{a}
libtxc-dxtn-s2tc:i386{ab} libuuid1:i386{a} libva-drm1:i386{a}
libva-x11-1:i386{a} libva1:i386{a}
libvdpau-va-gl1:i386{a} libvdpau1:i386{a} libvorbis0a:i386{a}
libvorbisenc2:i386{a}
libvpx4:i386{a} libwavpack1:i386{ab} libwebp6:i386{a}
libwebpmux2:i386{a} libwine:i386{a}
libwrap0:i386{a} libx11-6:i386{a} libx11-xcb1:i386{a}
libx264-148:i386{a} libx265-95:i386{a}
libxau6:i386{a} libxcb-dri2-0:i386{a} libxcb-dri3-0:i386{a}
libxcb-glx0:i386{a}
libxcb-present0:i386{a} libxcb-render0:i386{a} libxcb-shm0:i386{a}
libxcb-sync1:i386{a}
libxcb1:i386{a} libxcomposite1:i386{a} libxcursor1:i386{a}
libxdamage1:i386{a} libxdmcp6:i386{a}
libxext6:i386{a} libxfixes3:i386{a} libxi6:i386{a}
libxinerama1:i386{a} libxml2:i386{a}
libxrandr2:i386{a} libxrender1:i386{a} libxshmfence1:i386{a}
libxslt1.1:i386{a} libxtst6:i386{a}
libxvidcore4:i386{a} libxxf86vm1:i386{a} libzvbi0:i386{a}
mesa-va-drivers:i386{a}
mesa-vdpau-drivers:i386{a} ocl-icd-libopencl1:i386{a}
uuid-runtime{a} va-driver-all:i386{a}
vdpau-driver-all:i386{a} wine32:i386 zlib1g:i386{a}
0 packages upgraded, 156 newly installed, 0 to remove and 20 not upgraded.
Need to get 81.0 MB of archives. After unpacking 483 MB will be used.
The following packages have unmet dependencies:
libcups2 : Breaks: libcups2:i386 (!= 2.2.3-2) but 2.2.1-8+deb9u2 is
to be installed
libcups2:i386 : Breaks: libcups2 (!= 2.2.1-8+deb9u2) but 2.2.3-2 is installed
libtxc-dxtn-s2tc:i386 : Conflicts: libtxc-dxtn0 which is a virtual
package, provided by:
- libtxc-dxtn-s2tc0
(0~git20131104-1.1), but 0~git20131104-1.1 is installed
- libtxc-dxtn-s2tc
(1.0+git20151227-2), but it is not going to be installed
libtxc-dxtn-s2tc0 : Conflicts: libtxc-dxtn0:i386 which is a virtual
package, provided by:
- libtxc-dxtn-s2tc:i386
(1.0+git20151227-2), but 1.0+git20151227-2 is to be installed
libwavpack1 : Breaks: libwavpack1:i386 (!= 5.1.0-1) but
5.0.0-2+deb9u2 is to be installed
libwavpack1:i3
Re: [DNG] [OT] Restricting user capabilities after ssh login
On 08/13/2018 10:45 AM, info at smallinnovations dot nl wrote: > On 13-08-18 09:40, Lars Noodén wrote: >> On 08/13/2018 10:36 AM, info at smallinnovations dot nl wrote: >>> On 13-08-18 09:31, Lars Noodén wrote: >>> >>> >>> I worked the other way, Apache is able to work with symlinks. I only >>> needed to make www-data member of the users group. >> Eek. Think instead 'least privilege' That would be one situation where >> adding an ACL would work. That would avoid giving away (potentially) >> all the user's files to the web server. >> >> /Lars > > It is not really different from allowing user access to > /var/www/html/website. When a user puts all his user's files there (s)he > give away (potentially) all the files to the webserver too. As a member of the user's group, if something breaks out of the web server's document root then it has full read access to ~user and its subdirectories. In some files or directories that could also be write access. ACLs are a pain though since they are rarely used and can be complicated. /Lars ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Restricting user capabilities after ssh login
On 13-08-18 09:40, Lars Noodén wrote: > On 08/13/2018 10:36 AM, info at smallinnovations dot nl wrote: >> On 13-08-18 09:31, Lars Noodén wrote: >> >> >> I worked the other way, Apache is able to work with symlinks. I only >> needed to make www-data member of the users group. > Eek. Think instead 'least privilege' That would be one situation where > adding an ACL would work. That would avoid giving away (potentially) > all the user's files to the web server. > > /Lars It is not really different from allowing user access to /var/www/html/website. When a user puts all his user's files there (s)he give away (potentially) all the files to the webserver too. Grtz Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Restricting user capabilities after ssh login
On 08/13/2018 10:36 AM, info at smallinnovations dot nl wrote: > On 13-08-18 09:31, Lars Noodén wrote: > > >>> BTW I use this configuration combined with a symbolic link from >>> /var/www/html/website to /home/%u/website. This way it is much safer >>> then ftp, they cannot login while they still are able to maintain their >>> own website. Rsync over SSH is another possibility but SFTP looks more >>> like FTP and is more user friendly. >>> >>> Grtz >>> >>> Nick >> Hmm. symlinks should not work to reach targets outside the chroot. >> However, if you are on GNU/Linux you can use a bind mount. >> >> sudo mkdir www >> sudo mount --bind /var/www/html/website/ ./www/ >> >> It can be made permanent in /etc/fstab too. >> >> /Lars > > I worked the other way, Apache is able to work with symlinks. I only > needed to make www-data member of the users group. Eek. Think instead 'least privilege' That would be one situation where adding an ACL would work. That would avoid giving away (potentially) all the user's files to the web server. /Lars ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Restricting user capabilities after ssh login
On 13-08-18 09:31, Lars Noodén wrote: >> BTW I use this configuration combined with a symbolic link from >> /var/www/html/website to /home/%u/website. This way it is much safer >> then ftp, they cannot login while they still are able to maintain their >> own website. Rsync over SSH is another possibility but SFTP looks more >> like FTP and is more user friendly. >> >> Grtz >> >> Nick > Hmm. symlinks should not work to reach targets outside the chroot. > However, if you are on GNU/Linux you can use a bind mount. > > sudo mkdir www > sudo mount --bind /var/www/html/website/ ./www/ > > It can be made permanent in /etc/fstab too. > > /Lars I worked the other way, Apache is able to work with symlinks. I only needed to make www-data member of the users group. Grtz Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Restricting user capabilities after ssh login
On 08/13/2018 10:10 AM, info at smallinnovations dot nl wrote: > On 13-08-18 03:31, mett wrote: >> On Sun, 12 Aug 2018 13:18:23 +0200 >> info at smallinnovations dot nl wrote: >> [snip] >>> That part of my sshd_config looks like: >>> >>> Subsystem sftp internal-sftp >>> Match group sftponly >>> ChrootDirectory /home/%u >>> X11Forwarding no >>> AllowTcpForwarding no >>> ForceCommand internal-sftp [snip] > BTW I use this configuration combined with a symbolic link from > /var/www/html/website to /home/%u/website. This way it is much safer > then ftp, they cannot login while they still are able to maintain their > own website. Rsync over SSH is another possibility but SFTP looks more > like FTP and is more user friendly. > > Grtz > > Nick Hmm. symlinks should not work to reach targets outside the chroot. However, if you are on GNU/Linux you can use a bind mount. sudo mkdir www sudo mount --bind /var/www/html/website/ ./www/ It can be made permanent in /etc/fstab too. /Lars ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Restricting user capabilities after ssh login
On 08/13/2018 08:06 AM, Didier Kryn wrote: > But allowing ssh connections with a restricted shell permitting only > the commands used by rsync could be the way. But you would probably need > to forbid the fancy features of ssh, like port forwarding. If they use SSH keys (and only keys) for authentication then rsync restrictions can be set in the authorized_keys file but requires a bit of fiddling to get the right options. Running rsync with the SSH client in verbose mode gives you the details needed to set in the key file: rsync -e 'ssh -v' -avH /some/source/dir u@there:/some/dir/ Then see 'command="command"' in the AUTHORIZED_KEYS FILE FORMAT section of the manual page for sshd(8) for that. Once done, that is rather solid on its own but could still be used in conjunction with a restricted shell. The prerequisite is for a locked down SSH key is that the group of users to be affected doesn't have access the authorized keys files. The accounts need to be able to read their own own keys but not write them. And perhaps it is best if it cannot read the keys for other accounts. Match Group lockedin AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys Or something similar if you are more careful with the file permissions. Match Group lockedin AuthorizedKeysFile /etc/ssh/authorized_keys/%u What scale are you looking at, 10s, 100s, 1000s, or more? /Lars ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Restricting user capabilities after ssh login
On 08/13/2018 04:29 AM, mett wrote: [snip] > To be honest, rbash is what I thought of, first. > > 2 things refrain me from using it: > -user cannot cd in his subdirectories [snip] Ok. That is potentially a big barrier. > -the wikipedia example of writing 'bash' at the command line > and then being able to access everywhere(I tried it). That would be only if the $PATH environment variable is not set properl. You could forcibly set $PATH to /usr/local/rbin for example and then populate that directory with the allowed programs: sudo mkdir /usr/local/rbin; sudo ln /bin/ls /usr/local/rbin/; sudo mv /bin/mv /usr/local/rbin/; sudo rm /bin/rm /usr/local/rbin/; . . . You can use symbolic links in the restricting bin directory instead if the restricted PATH directory is on a different partition from the originals or if that style is nicer. /Lars ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Restricting user capabilities after ssh login
On 13-08-18 03:31, mett wrote: > On Sun, 12 Aug 2018 13:18:23 +0200 > info at smallinnovations dot nl wrote: > >> On 12-08-18 06:55, mett wrote: >>> Hi, >>> >>> I m wondering about the best way to restrict a user after >>> he has ssh'd into his web folder. >>> >>> Up to now, the users I had were using only FTP >>> to log into their web folder, >>> and upload stuff in there >>> (chrooted in their folder with vsftpd). >> >>> The setup is a devuan server under jessie with apache2 providing >>> http server. >>> Then, I use php-fpm to tie user, web-server and php processes. >>> The passwd files is as below: >>> 'user01:x:::user01,,,:/home/www/example.com/:/bin/bash'. >>> >>> TIA >>> ___ >>> Dng mailing list >>> Dng@lists.dyne.org >>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> When you intend to replace ftp you can start with limiting the user to >> use sftp only. No need to have a login shell. >> >> That part of my sshd_config looks like: >> >> Subsystem sftp internal-sftp >> Match group sftponly >> ChrootDirectory /home/%u >> X11Forwarding no >> AllowTcpForwarding no >> ForceCommand internal-sftp >> >> >> Grtz. >> >> Nick >> >> >> >> ___ >> Dng mailing list >> Dng@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > Thanks a lot for the input. > I ll definitely have to do it at one point. > > Cheers, BTW I use this configuration combined with a symbolic link from /var/www/html/website to /home/%u/website. This way it is much safer then ftp, they cannot login while they still are able to maintain their own website. Rsync over SSH is another possibility but SFTP looks more like FTP and is more user friendly. Grtz Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
