Re: [DNG] [devuan-dev] [PATCH] (security) launcher: don't attempt to execute arbitrary binaries
Hello Enrico, On dt., gen. 07 2020, Enrico Weigelt wrote: What might supposed to be convenience functionality, poses a real-life security threat: A user can be tricked be tricked to download malicious code, unpack it with +x permissions (eg. via tar) and execute it by just clicking on the icton. In combination with other techniques (eg. homoglyphs), even more experienced users can be tricked "open" some supposedly harmless file type, while Thunar in fact executes a binary - with full user's privileges. (the same approach is one of the primary infection vectors used by thousands of malwares in Windows world, which already caused gigantic damages). Therefore introduce a new setting and only execute programs if explicitly enabled. That's great! Have you tried poking Thunar's developers into merging such a feature? This is where the developers would like such things: https://docs.xfce.org/xfce/thunar/bugs It'd really be the best place for a setting like this to land and benefit all Thunar users out there (which are not limited to Debian-like or even Linux, but also include the BSDs). Cheers! -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I wrote IBM
On dg., set. 29 2019, goli...@devuan.org wrote: On 2019-09-28 21:32, Steve Litt wrote: Hi all, I just wrote IBM asking them to reconsider systemd, given that IBM's business model is different from the old Red Hat's. [cut] I encourage all of you to write IBM. If I'm right and it helps, this would prevent future incompatibilities requiring significant increases in Devuan development effort, just to stay even. If I'm wrong, you lose a couple hours writing a letter. The web page for this letter writing campaign is as follows: Sorry Steve . . . I think this idea is naive, ill-advised and a tactical error that could have very real, unintended consequences. I do hope that neither Devuan nor s6 was mentioned in the letter that you sent. golinux +1. That's shy of stalking, does nothing productive to move forward your goal and, indeed, is counterproductive mid and long-term. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] why does mount expect NTFS?
Hey, On dg., ag. 11 2019, Hendrik Boom wrote: So I want to find out what's in /dev/sda4 on my hard drive. The computer has *never* had Windows on it. So I try to mount it, and am told: april:/farhome/hendrik# mount /dev/sda4 /test NTFS signature is missing. Failed to mount '/dev/sda4': Invalid argument The device '/dev/sda4' doesn't seem to have a valid NTFS. Just adding two things to what marc wrote: partition number 4 (sda4) is very often used as the extended partition in DOS partition tables. Regardless of its type, you should check the partition table; it will have the type byte set for each partition which says which use it's supposed to have, though it can actually not match the partition contents. I recall gparted and IIRC parted show this quite nicely. man parted was useful (at the very least the help command was). If it is an extended partition, then it's not supposed to be mountable, but you should check the 5th partition instead. Another fun thing that will work even if you are not using a DOS partition table is: just hexdump it! dd if=/dev/sda4 bs=1M count=1 | hd | less File systems usually have some kind of readable ASCII information at the beginning and amongst others an NTFS partition will be obvious there. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mirror 141.84.43.19 - Frequent unavailability
Final update on this so it doesn't stay "open" forever: On dc., jul. 17 2019, Evilham wrote: On dc., jul. 17 2019, Bernard Rosset via Dng wrote: b) If not and this a confirmed defect, would not it be reasonable to remove said host from the pool until the maintainer can inspect what is going on and act on it? If we get more reports we totally will, so far everything is "looking good" and all tests pass, but maybe there is indeed something inherently spotty on the connection and that's what you are seeing; we'll see if with more data or more reports or when the maintainer takes a look something changes. Mirror maintainer confirmed very quickly that it was a hiccup they were dealing with by the time Bernard ran into it an ran his tests, so there is no need for further action regarding the particular mirror since, as we observed, it's back to normal. The connection-level monitoring should happen though :-). -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mirror 141.84.43.19 - Frequent unavailability
On dc., jul. 17 2019, Bernard Rosset via Dng wrote: Thx Evilham for your answer. Glad it was not sinkholed ;o) Not at all :-). But maybe it'll be interesting to add simple monitoring at a connection level same way you ran your tests. I'll try to setup a thing in the next couple days. I was actually thinking about ways of involving the community, whose kind members already are actively participating in mirrors & such, in a distributed monitoring array. While heavy checks might be run on more central, tighly-controlled components, availability checks could be run from anyone's scheduled tasks manager, and might be aggregated as "pods" in (a) monitoring instance(s) responsible to store & display results? I was thinking simple checks run as scheduled tasks, collection through rsyslog. For the displaying part YMMV, depending on which you merely wanna display or allow viewers to query on the dataset... hence either a static display or more evolved stuff like Grafana. Has anyone built such a thing recently with maybe more proper architectures, yet agent-less, than this one? The usual monitoring setups I encountered so far tended to be locked to the previously chosen tech... for better or worse. Decoupling is good. This would pave the way for check coming from many networks/IX/equipments/hosters, etc. balancing/nullifying observation biases. Interesting idea, but that opens a weird can of worms, e.g. quality and reliability of the data, biases, even privacy and a bunch of things that won't come to me right now. So, it *is* interesting, but it may be a bit of an overkill for this particular instance of this class of issues? Regarding public grafana dashboards, they have an issue, and it's that by having a public dashboard you effectively disclose the whole data source since grafana only acts as a proxy that passes queries to the data source. It's pretty trivial as well, just use the network tab and find the API calls, open in a new tab and modify the query away :-). https://community.grafana.com/t/how-to-make-one-live-dashboard-public/12819/2 It may not be a problem if you consider the data source to be public anyway. FWIW, when I said "I'll see if I can set up sth", I had in mind a thing we started as a PoC on a public status page, but it hasn't been brought up to being actually working publicly, e.g. for Devuan. https://github.com/evilham/prometheus-adlermanager If we get more reports we totally will, so far everything is "looking good" and all tests pass, but maybe there is indeed something inherently spotty on the connection and that's what you are seeing; we'll see if with more data or more reports or when the maintainer takes a look something changes. IIUC, this lack of detection seems to be coming from the lack of monitoring... hence my ping/call to the community :o) Anyone jumping on board is warmly welcome! Oh, there is monitoring, it's just, you know, you can always monitor more and better :-p. In any case, just be respectful towards the mirror admins and don't do crazy things like checking that everything is equal bit to bit every 30 minutes :-). -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mirror 141.84.43.19 - Frequent unavailability
Hello, On dc., jul. 17 2019, Bernard Rosset via Dng wrote: After I stumbled, by chance, on mirror 141.84.43.19 (being part of the deb.devuan.org pool) being unavailable for a couple of minutes, I set a script up checking TCP/80 availability for all of mirrors in said pool. The conclusion is clear: 1°) 141.84.43.19 is the only mirror suffering from this problem 2°) This problem was detected with a high frequency, despite relatively infrequent checks (1 every 5 min) For this day only so far, 2019-07-17, at 1600Z, all the failed occurences were happening at those times: 0050Z 0055Z 0100Z 0105Z 0110Z 0115Z 0120Z 0123Z 0145Z 0150Z 0155Z 0200Z 0205Z 0230Z 0240Z 0245Z 0250Z 0310Z 0410Z 0420Z 0455Z 0510Z 0515Z 0520Z 0535Z 0610Z 0615Z 0630Z 0640Z 0645Z 0715Z 0755Z 0800Z 0805Z 0825Z 0905Z 1035Z 1100Z Very interesting, we'll raise the issue with the mirror maintainer, thank you for going the extra mile than just shouting "it's not working". This report actually helps. Hence the following questions: a) Am I the only one observing this (ie someone else having set such a check up with a check frequency relatively close to mine, eliminating biases of my setup)? We have somewhat thorough mirror checkers in-place that haven't detected this, since they are thorough, they can't run too often as they can result in huge amounts of traffic. FWIW: I've been running "while; curl; sleep 30" as a similar test for a good few minutes now and it's been solid. But maybe it'll be interesting to add simple monitoring at a connection level same way you ran your tests. I'll try to setup a thing in the next couple days. b) If not and this a confirmed defect, would not it be reasonable to remove said host from the pool until the maintainer can inspect what is going on and act on it? If we get more reports we totally will, so far everything is "looking good" and all tests pass, but maybe there is indeed something inherently spotty on the connection and that's what you are seeing; we'll see if with more data or more reports or when the maintainer takes a look something changes. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] User services
\o/ this is pretty cool and significantly more than I thought would be the beginning. On dv., maig 10 2019, Martin Steigerwald wrote: And now feel free already to contribute your own services. :) I welcome merge requests. Let me just add: not only creating the Merge Requests, but also requesting support for X should also be helpful in that we get to know which packages and user-services are having issues with. Of course, ideally: contributed work is better than just asking for things to get done :-). Maybe the path to officially supporting runit can start by calling everyone who uses it one way or another to contribute some svdirs. There are quite some ideas on how to improve this initial proof of concept: - Make it work out of the box with .xprofile (or how that is called). /me looking to Evilham now :) There is not much to it really, a line I'd use in ~/.xprofile is something like: /usr/bin/runsvdir -P "$HOME/.services/enabled" "log: " & And it should start and stop along with the X session (I don't think it's a good idea to have these services start on regular sessions). - Make it work with other desktop environments out of the box Using the above should do that. - Make it handle groups of services in a clean and simple way - Make it work with s6 alternatively (may just need replacing runsvdir) - And of course add more services, … - including any of those relevant in /usr/lib/systemd/user/ - Putting it into a package. I am willing to package it at a later point in time. When discussing this, please make sure doing so constructively. Thanks a lot to Evilham for coming up with the idea to use runit for user services and for providing the initial service directories for the four services to make Evolution work. Thank you for looking into it and actually documenting it and improving on the whole thing. Now let's make more out of this by the power of together… and of course enjoy using it. Yes! -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] cannot reach gitlab
Didier Kryn writes: Hello. I have had a few authentication failures this morning trying to clone and push my project on Devian's gitlab. Now I get a timed out connection either with git or with my browser. Am I banned or did I crash the git server ? Sorry if I tried crazy actions. I'm new to git. Didier Hello, I took a quick look and don't see anything strange with your user / repos and things appear to be working alright on the server end. If you keep having issues maybe come around to IRC and with a more synchronous communication we can try to figure it out. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] New application ready to test: hopman
Am 24. April 2019 00:24:56 MESZ schrieb Steve Litt : >On Tue, 23 Apr 2019 12:22:44 +0200 >Didier Kryn wrote: > >> Hello Devuaneers. >> >> I have put on https://git.devuan.org/kryn/hopman an application >> to let mount/umount/open filesystems on hotplug mass storage devises >> such as USB sticks or SD cards. This is a replacements for features >> provided by Desktop Environments. > >[snip] > >OUT-standing > >I didn't have a ready to use Devuan VM, so I just installed it on Void >Linux. It worked perfectly, once I understood the deal. > >A lot of the stuff I report here might not happen on Devuan, but then >again I might find some errors or maloptimizations that might be edge >cases in Devuan. > >Anyway, I followed your compile instructions and it worked perfectly. >But when I ran hopman, I got a "Bus error" message running it as either >slitt or root. So I touched /home/slitt/.hopmanrc, got past the bus >error, but got another error. Infatiguable, I copied the entirety >of /etc/default/hopmanrc to ~/.hopmanrc, and the thing began to work. > >For those of you who haven't tried hopman yet, let me define "work". >You run hopman on the command line, and it sits there and spins. No >gui. *Until* you insert a thumb drive. Then, all of a sudden, the gui >pops up with the thumb's label. Left click the label line and you get >choices to open in filemanager, open in terminal, mount, or eject. >Regardless of what you set EjectHelper to in .hopmanrc, trying to eject >always errors saying "No command helper". This is true even if I set >the EjectHelper to the same string as UmountHelper in ~/.hopmanrc. I >have a hunch something's hard coded that shouldn't be. One of the >source >files (config.c I think) mentions there's no known EjectHelper. > >Hopman didn't show up anywhere on my lxpanel: I have a feeling that was >a design decision so hopman doesn't need to know the intracies of each >panel it interfaces with. > >Bottom line, a running Hopman shows a GUI window *only* if thumb drives >or USB harddisks are plugged in. > >Like almost every other mounter software, hopman gets itself in a crazy >state if you yank the thumb drive out before unmounting it. In this >crazy state, it tells you you can't unmount it because it's in use. >This also happened on my inotifywait based mounter (which another >Devuanner improved substantially). I'll research this more. > >I'm trying to create a runit run file for hopman and am having a little >trouble. I'll report back later. > >One more thing: Hopman is wonderful software. Very few dependencies, >easy as hell to compile. No ./configure step. No BS. The source is >fairly easy to read. It does one thing and does it well. This is how >all software should be written. > Thank you for the review! I had the feeling this would be quite nice :-). If I may recommend, open 3 issues on gdo (on phone, about to sleep, else I'd do it): 1. Improve documentation / UX by communicating the "No GUI until you plug sth" behaviour on stdout. 2. Either gracefully treat a packing rc dir or to create it automatically or just to have a good stderr message 3. Document the misbehaviour when users... Misbehave (okay, that was a bad joke). I think, 1 and 2 are easily actionable and, from what you described, would greatly improve the UX. 3 may be trickier. -- Evilham___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] New application ready to test: hopman
Didier Kryn writes: Hello Devuaneers. I have put on https://git.devuan.org/kryn/hopman an application to let mount/umount/open filesystems on hotplug mass storage devises such as USB sticks or SD cards. This is a replacements for features provided by Desktop Environments. It only depends on a linux kernel version newer than 2.2.26 and the GTK+-2 library, plus helper commands to mount/umount/open the filesystems, such as pmount/pumount, thunar and xfce4-terminal. That's great, thank you. The git repository contains a description of the project, plus a directory containing the source and makefiles. To instal: git-clone the project, then: cd hopman/hopman-1.0 make && make install # You must be root to install make cleanall Installed files: /usr/bin/hopman, /etc/default/hopmanrc, /usr/share/man/man8/hopman.8.gz,, /usr/share/pixmap/hopman.png, /usr/share/applications/hopman.desktop I tried to make it a Debian package, but with little success. I need help for that. I hope someone can devote some time to help with this. I also need help to remove from the gitlab a previous, primitive version which was named partmon. I transfered that repository to my user on gdo and if there are no complains I'll delete it in a couple weeks, I hope that's acceptable. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: April's fools mess
Am 9. April 2019 10:53:40 MESZ schrieb aitor : >Hi all, > >On 4/2/19 7:35 PM, Andrew McGlashan wrote: >> Many April Fools are done/around/ the time of 1st April some >get >> in early on purpose, irregardless of time zones. >> >> Still, moving on; we've been promised that this won't happen again. >> >> Thank you. >> >> Cheers >I didn't know about april's fools until this all happened because of >our >different traditions: we use to do this sort of jokes on 28 December, >called "El día de los inocentes" and which, as you will remember, >coincided with the death of Ian Murdoch. During this incident happened >I was preparing my travel to Amsterdam and I couldn't take time off to >follow the thread closely, even being aware that something serious >happened. In spite of I try to mantain aside of this kind of incidents >(in part because english is not my native language and I can >misundertand >messages), i'll draw a positive conclusion... People involved in the >incident have been in Amsterdam during these days because all of them >love Devuan the project. They are mature people, and mature people try >to understand the emotions and reasoning of others. >Seeds of discord comming from the distance are insane :-) Well put, thank you Aitor and Andrew! Indeed dev1-conf was (and is being) very positive for many aspects of the project and this is just one of them. -- Evilham___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What you saw on devuan.org yesterday was an April's fools joke
Jaromil writes: he is now in moderation. if the trolling comes back from other accounts please don't feed. Thank you, I was coming to suggest that as well. The whole going-for-blood-or-else thing was getting on my nerves. People particularly concerned with security did the sensible thing as a temporary measure and with all the assurances already given, are back to normal as there is indeed no ill-intent or reason to distrust the people with access to infrastructure. Also thank you for the non-exhaustive list of KatolaZ' contributions; I didn't personify this, even if he apologised (which is indeed highly appreciated), because I don't consider this event a few people's fault, but something to be analysed and solved to avoid issues in the future. In my experience, blaming never solves things. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: April's fools mess
Mike Bird writes:
On Mon April 1 2019 14:18:38 Martin Steigerwald wrote:
For me that is good enough.
When core team member Evilham writes "it still looks as
if gdo and the build system were compromised" [1] I need a
lot more than a limited admission of guilt from KatolaZ
before trusting that Evilham was mistaken rather than
KatolaZ just managed to hide his tracks better.
Obviously, even when trying, it is impossible to pick words in a
perfect
way since natural language is imprecise.
You are reading too much into that phrase.
In the context, it referred to the "pwned site" (still viewable)
**claiming** ("looks as") that gdo had been compromised.
If you read a paragraph further, that point is made very clear,
when I
mention that the "joke" wouldn't have been half as bad if it had
been
limited in scope to the plain devuan-web.
I kindly ask you not to read things that are not there and jump to
conspirations, it is what it is: a fuck up, a beautifully executed
one,
but a fuck up and a recognised one at that.
Discussing at this length what the fine letter said is not going
to help
move things forward, quite the opposite.
Again: there is no reasonable ground to think devuan the signing
keys
have been compromised or anyone with access to infrastructure is
acting
with ill-intention.
This email could have been signed, but being abroad and all,
access is
not the most trivial and it likely won't suffice for you, so I
have
better things to do, like sleeping!
--
Evilham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: April's fools mess
Evilham via Dng writes: Evilham via Dng writes: (*): **to my knowledge** means that I am still trusting the communications and the project, even if I decided keep in place the temporarily disconnect of my systems from devuan's infra. FWIW if anyone cares, I checked what I could and things under my control are back to using devuan's infra. Everyone please abstain from escalating things forward, suggesting kicking someone out of the project or taking legal actions is premature; and claiming it's a harmless joke and everything is fine is is also missing the point. If I disconnected my systems from Devuan's infra was because it was the prudent thing to do while things were clarified, if I am satisfied with shallow tests is because I have no real reason to believe this was but a misdirected prank with all the "buts" I explained before. That message was just intended to help those who are so rightfully concerned about this see, that their views are also being taken into account and not ridiculed and left forgotten. My guess is that this will be discussed at length... Yes, at dev1conf, in person, where text will be much harder to be misinterpreted than on emails. Until then, speculation and pointless debates are just noise. And if it has become personal, take it to a private space. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: April's fools mess
Evilham via Dng writes: (*): **to my knowledge** means that I am still trusting the communications and the project, even if I decided keep in place the temporarily disconnect of my systems from devuan's infra. FWIW if anyone cares, I checked what I could and things under my control are back to using devuan's infra. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Speak now, or forever hold your peace
Am 24/10/2018 um 0:58 schrieb Steve Litt: > Hi all, > > I'm about to start adapting runscripts to Devuan ASCII. Many/most > daemons do log messages themselves, but for the ones that don't, I'll > be using logger to capture stdout and stderr and put them in the logs. > > If anybody has an objection to this, speak now or forever hold your > peace. > Hello Steve, thanks for working on this :-). I myself use runit, quite a bit. Not as an init system though, but it'd interesting. Now, disclaimer: I've had a busy week and haven't thoroughly read on the thread that seemed to be about this; so I may have missed something important. I'll just add that when I use runit, I use svlogd. The main reason for this being that it is guaranteed to just do the right thing with the signals sent by sv and it is flexible enough. That being said, logger probably does work well; I just haven't given it a shot :-). Basically: if I were to do this, I'd probably go with svlogd because it feels more future-safe (packaged together, signal interactions documented, thought to work with runit). But also it is unlikely that logger changes too much to make it incompatible with runit. -- Evilham signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs [solved]
Am 16/10/2018 um 10:46 schrieb Didier Kryn: > > Any reading to recommend about recursive, authoritative or what else > name servers ? IIRC it doesn't cover everything and by no means is it technical, detailed or deep, but it's way too cute not to mention it: https://howdns.works/ -- Evilham 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] Cannot install wine32 on ASCII.
Am 17.08.2018 um 10:27 schrieb Edward Bartolo: > On 13/08/2018, KatolaZ wrote: > [...] >> >> 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. >> > > I carefully edited my sources.list file as indicated above. I also > edited similar files that were under /etc/apt/sources.list.d. The > result is still the following: > > - > # apt-get install wine wine32 wine64 libwine libwine:i386 fonts-wine > 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: > 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 > 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. > --- > > I usually do not use wine, but at this time, I am learning LTSpice. > Please, do not tell me to use Linux circuit simulators. Online, I have > to communicate with people who only use Windows and they are usually a > great help in circuit design and analysis. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > Snippet from a previous email after fixing command typos, can you post all this? 1. dpkg --print-architechture 2. dpkg --print-foreign-architectures 3. list of enabled repositories (+ architechture) 4. dpkg -l | grep wine -- 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 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
Re: [DNG] [OT] Cannot install wine32 on ASCII.
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:i386 : Breaks: libwavpack1 (!= 5.0.0-2+deb9u2) but > 5.1.0-1 is installed > libmpg123-0 : Breaks: libmpg123-0:i386 (!= 1.25.0-1) but 1.23.8-1+b1 > is to be installed > libmpg123-0:i386 : Breaks: libmpg123-0 (!= 1.23.8-1+b1) but 1.25.0-1 > is installed > libp11-kit0 : Breaks: libp11-kit0:i386 (!= 0.23.3-5) but 0.23.3-2 is > to be installed > libp11-kit0:i386 : Breaks: libp11-kit0 (!= 0.23.3-2) but 0.23.3-5 is > installed > libtasn1-6 : Breaks: libtasn1-6:i386 (!= 4.12-2) but 4.10-1.1+deb9u1 > is to be installed > libtasn1-6:i386 : Breaks: libtasn1-6 (!= 4.10-1.1+deb9u1) but 4.12-2 > is installed > libpng16-16 : Breaks: libpng16-16:i386 (!= 1.6.29-3) but 1.6.28-1 is > to be installed > libpng16-16:i386 : Breaks: libpng16-16 (!= 1.6.28-1) but 1.6.29-3 is > installed > open: 342; closed: 3154; defer: 30; conflict: 33 > oThe following actions will resolve > these dependencies: > > Remove the following packages: > 1) libtxc-dxtn-s2tc0 [0~git20131104-1.1 (now)] > > Keep the following packages at their current version: > 2) libasound2-plugins:i386 [Not Installed] > 3) libavcodec57:i386 [Not Installed] > 4) libcairo2:i386 [Not Installed] > 5) libcups2:i386 [Not Installed] > 6) libfontconfig1:i386 [Not Installed] > 7) libfreetype6:i386 [Not Installed] > 8) libgnutls30:i386 [Not Installed] > 9) libldap-2.4-2:i386 [Not Installed] > 10) libmpg123-0:i386 [Not Installed] > 11) libp11-kit0:i386 [Not Installed] > 12) libpng16-16:i386 [Not Installed] > 13) libtasn1-6:i386 [Not Installed] > 14) libtheora0:i386 [Not Installed] > 15) libwavpack1:i386 [Not Installed] > 16) libwine:i386 [Not Installed] > 17) libzvbi0:i386 [Not Installed] > 18) wine32:i386 [Not Installed] > > Leave the following dependencies unresolved: > 19) libgl1-mesa-dri recommends libtxc-dxtn-s2tc | > libtxc-dxtn-s2tc0 | libtxc-dxtn0 > > > > Accept this solution? [Y/n/q/?] > > Obviously, I chose 'q'. > > > 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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Python modules SimpleHTTPServer / SocketServer
Am 12.08.2018 um 13:12 schrieb leloft:
> Hello to everyone,
>
> I am trying to build a devuanized version of the debian
> security-tracker, but I have strayed very far from my skills base!
> Give or take a few untidy loose ends inherited from the
> debian oldoldstable and lts sections of the Makefile, the security
> database appears to build ok with devuan variables. I can confirm this
> in principle by cursory examination of a text file dump of the contents;
> as this file is >300Mb, this is hopelessly inadequate, but so
> far, so good.
>
> However, the process is halting at the creation of the python server.
> The problem is the same in 4 environments, and is the same with ordinary
> user and root privileges:
>
> 1) a headless 'dist-upgraded' ascii environment,
> 2) a chrooted 'minbase' ascii environment and
> 3) a chrooted 'minbase' debian stretch environment
> 4) a desktop machine running a 'dist-upgraded' ascii,
>
> Specifically, the process hangs during the
> SocketServer process:
>
> ^CTraceback (most recent call last):
> File "tracker_service.py", line 1773, in
> TrackerService(socket_name, db_name).run()
> File "../lib/python/web_support.py", line 840, in run
> self.server.serve_forever()
> File "/usr/lib/python2.7/SocketServer.py", line 231, in serve_forever
> poll_interval)
> File "/usr/lib/python2.7/SocketServer.py", line 150, in _eintr_retry
> return func(*args)
> KeyboardInterrupt
>
> The problem can be reproduced with this command
>
> $ python -m SimpleHTTPServer
>
> Serving HTTP on 0.0.0.0 port 8000 ...
> ^CTraceback (most recent call last):
> File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
> "__main__", fname, loader, pkg_name)
> File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
> exec code in run_globals
> File "/usr/lib/python2.7/SimpleHTTPServer.py", line 235, in
> test()
> File "/usr/lib/python2.7/SimpleHTTPServer.py", line 231, in test
> BaseHTTPServer.test(HandlerClass, ServerClass)
> File "/usr/lib/python2.7/BaseHTTPServer.py", line 610, in test
> httpd.serve_forever()
> File "/usr/lib/python2.7/SocketServer.py", line 231, in serve_forever
> poll_interval)
> File "/usr/lib/python2.7/SocketServer.py", line 150, in _eintr_retry
> return func(*args)
> KeyboardInterrupt
>
> Has anyone any experience of whether these commands work/have worked
> 'out of the box' for them in an ascii installation? I cannot find any
> posts online that report any problems with the module, so I am assuming
> it is unique to me, unless someone has reproduced it on a different
> ascii machine.
>
> Ideas and insights or workarounds would be very welcome.
>
> Many Thanks
>
> leloft
>
<3 I've been following your DSA work, that's very awesome, thank you!
I just gave it a go on a (fresh-ish) VM and it appears to work:
0. apt-get install git make python-{apt,apsw}
1. git clone
https://salsa.debian.org/security-tracker-team/security-tracker.git
2 test that it works with debian config:
2.a make update-packages
2.b make
2.c make serve
This may be the place you reached: this now runs a web server,
leave this command running.
2.d curl http://127.0.0.1:10605/tracker/status/release/oldstable | less
This should show you a bunch of HTML with some CVE data.
2.e Finish the make serve command (CTRL+C)
2.f make clean
3. Edit Makefile accordingly
4. Edit lib/debian-releases.mk accordingly
5. Check if it works with devuan config, basically repeat 2.
For the changes I made in steps 3 and 4 check:
https://git.devuan.org/evilham/security-tracker/commit/2515688e17116ee28b735fc85df9a18fab6a44bd
Notice that they reflect the different repo structure for Devuan (also
that I left only one .mk file, having multiple leads to make warnings).
To keep the scripts happy, I also limited the architectures listed, e.g.
there is no ascii-updates/non-free/binary-mips in our repos.
@parazyd: is this a bug in Amprolla or is it by design? Would it make
sense to create an "empty" repository in those cases? I know this is
easily patchable in these scripts, but *maybe* it is a desirable thing
for Amprolla as a whole and is not too difficult.
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!).
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 li
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
Am 08/11/2017 um 12:18 schrieb Alessandro Selli: > The "my own PC has been like this so many years" reasoning is a very poor > justification for a design decision that impacts users that run their > systems in the most diverse scenarios and environments, just like the "this > (bad) decision was made many years ago" one. 3 words: Universal Operating System -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
Am 07/11/2017 um 17:00 schrieb Klaus Ethgen: > The first broken version is 2.02.175-1, or other way, the last working > version is 2.02.173-1. > >> So, could you please also file a bug report in Devuan with a link to >> Debian's bug report? Use bugs.devuan.org for that. > Done. > >> Change log and WHATS_NEW file don't contain mentions of a >> similar-sounding issue. The only thing fixed regarding 2.02.175 is: >> - Fix detection of moved PVs in vgsplit. (2.02.175) >> Which doesn't sound like your problem. >> It wouldn't hurt to try to chroot your way into the system and upgrade >> the package though. > Well, The problem is that I _did_ an upgrade and ended with a unbootable > system. I had to boot with grml and installed version 2.02.173-1 what > fixed the problem. > > ldd do show the dependencies to /usr if you want to check yourself. Thank you! Actually, John's last email explains it all :) I didn't go that far in the troubleshooting right now. That bug report should help make sure we don't land that beyond our unstable regardless of what Debian does with it. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
Am 07/11/2017 um 16:22 schrieb Evilham: > This is currently the last pushed commit (Release 2.02.178-1): > https://gitlab.com/debian-lvm/lvm2/commit/90bc98f3828032a1ad24daf14e2e2f2f704f1bd6 I meant 2.02.175-1, of course. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
Hallo Klaus, Am 07/11/2017 um 15:29 schrieb Klaus Ethgen: > today I suffered by a heavy bug in lvm2. With version 2.02.175-1 it > starts to depend on library in /usr. > > If you have an seperate /usr (what is not supported by the ignorance of > systemd) and that /usr on lvm and a kernel with no initrd (what does not > exist in the ignorance of systemd), then you are doomed and your system > will not boot anymore. > > How is that going in devuan? Will it be repaired? I already filled an > bugreport in debian but I believe it will be closed as wontfix by This is quite serious. If you found the issue only appears with 2.02.175-1, Devuan Jessie and Ascii would be safe, so no need to worry yet. We do have to keep track of how (and if) it gets fixed in Debian. So, could you please also file a bug report in Devuan with a link to Debian's bug report? Use bugs.devuan.org for that. Just mentioning that the current version in Debian Sid is 2.02.176 and I can't find a git repository that includes those changes... This is currently the last pushed commit (Release 2.02.178-1): https://gitlab.com/debian-lvm/lvm2/commit/90bc98f3828032a1ad24daf14e2e2f2f704f1bd6 Change log and WHATS_NEW file don't contain mentions of a similar-sounding issue. The only thing fixed regarding 2.02.175 is: - Fix detection of moved PVs in vgsplit. (2.02.175) Which doesn't sound like your problem. It wouldn't hurt to try to chroot your way into the system and upgrade the package though. -- Evilham signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What is devuan-dev and a dev-meeting?
Hello Edward, Am 05/09/2017 um 9:18 schrieb Edward Bartolo: > What is devuan-dev and a dev-meeting? Why on DNG there are no > discussions about software being developed or modified for Devuan? > There are discussions of 'software', but these, are more like > philosophico-technical debates. devuan-dev may refer to either a freenode IRC channel where devs are usually around or to another Mailing List. The devuan-dev ML serves for development discussion, DNG is (as I understand) more of a user-focused Mailing List. Important topics that affect users directly get raised here, like the eudev naming thing you've probably seen around. dev-meetings are announced via the devuan-dev ML and a pad is prepared prior, during and after the meeting; a final version gets sent to that ML as well. > As the person who coded and uploaded simple-netaid-backend and > simple-netaid-gui, am I missing something not "attending" these > dev-meetings? If you want to help with packaging (which is sth badly needed right now), hanging out on the IRC channel might be enough. The meetings do serve some organisational purpose / enable quick discussion and you may find out about stuff you wouldn't otherwise, so do feel encouraged to join in and introduce yourself :). If you are new around, you may be wondering about "lack of activity", this was caused by August being basically a dead month in the EU where most devs are located; as September kicks in, we should be seeing more things happening. FYI, the devuan-dev ML (there's a public archive there as well): https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] git.devuan.org -- 2FA issues
Am 30/08/2017 um 14:15 schrieb Andrew McGlashan: > Whatever code GA gives will never work as the git.devuan.org server is > more than 2 minutes fast. I thought this was a minor annoyance when commit / issues / ... were shown as taking place "in two minutes" but, *of course* that's going to break 2FA '^^; hadn't gotten around to setting that up yet. Good catch everyone. Copied Centurion_Dan here, so he is aware and gets around to fixing that at some point. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] opinions and experience with monit
Hello :), Am 22/08/2017 um 17:54 schrieb Jaromil: > > dear DNG'ers > > on my quest to study more supervision programs for my own use, I've > found out (just now!) about monit: > > https://mmonit.com/monit/ > > I'm wondering if you have experiences using it and what are your > opinions, it seems to me that is a well written, minimal enough > addition to sysvlinux when more features are desirable but no > entanglement is aloud. > > is there someone here who knows it / has already experience with it? Remember I set up Monit alerts for most of Devuan's infra a few weeks ago and they've been quite helpful :-). IMO: Monit is *very good* at a few things, so it depends on what your use case is. Hopefully I explain properly what these things are: If you are only managing one server, or only want alerts (i.e. not act, only notify) about multiple servers, Monit is definitely a good way to go; it's very easy to set up and does its job quite well. If, on the other hand, you have multiple machines you would like to act upon, you should really go with something like Nagios. A couple tips that may make it easier: - Monit's default message format is awful, do customise it :). - It is possible to set up custom alerts for specific events (e.g. That's what I do with Devuan related tests, the Monit instance does plenty of checks besides those of Devuan). - Networks are unreliable. If you are implementing network checks against other hosts; you should make use of the "for X times within Y cycles", that will ensure that network hiccups won't trigger an alert of something that is not going to be an issue. A downside of this is, you don't get that information in the notification, e.g. if you have a cycle of 1 minute and say check "for 3 times within 5 cycles": your alert will say "failure at 10.11 am", but it will imply that the service is probably down since 10.09 (3 failures in 5 minutes). - You *can* run arbitrary scripts when something happens (or to check against the script's result / output). This gives you tons of flexibility; if you do that for too many things though, you may be better off checking Nagios :). I hope that helps, -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] auto.mirror.devuan.org or us.mirror.devuan.org
Am 20/08/2017 um 12:50 schrieb tirveni yadav: > Currently, Both the hostnames us.mirror.devuan.org and > auto.mirror.devuan.org are pointing to packages.devuan.org. > > And packages.devuan.org is pointing to an IP in pool of ovh, France. > > So, there's no difference. Pretty sure that's accurate, XY.mirror.devuan.org, where XY is a country code should all be resolving to the same IP address. IIRC, when the package mirror network is setup (plans are for it to start soon), auto.mirror would send you to the closest mirror, so if you move around, that'd be best for you; if you'd rather use a specific country mirror, you should use that instead. Keeping in mind, that while the package mirror network is deployed, they all resolve to the same IP in France. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan presentation at Chemnitzer Linux-Tage (Germany) 2018?
Salut Narcís! Good to see you here (we've crossed emails on debian's CA user list). Am 14/08/2017 um 12:59 schrieb Narcis Garcia: > I suggest to put effort on explaining what are and how are init systems > with stages, supervision, freedom, etc. > Sounds like a good idea. > El 14/08/17 a les 11:49, Michael Siegel ha escrit: >> As for the topic of the talk, I was thinking of a general introduction >> to Devuan, i.e. something like: * What is Devuan? Since the answer to this right now is basically "Debian without systemd", it totally begs next point. * What is an init system? Supervision? Why is that freedom important? * Why and how did it come about? "Why" should be mostly addressed by previous point, worth making it clear again here though. * How does the process of creating releases for this distribution work? * Why should users / debian ecosystem care? This would include the previous "what does Devuan have to offer" while leaving romom for more. * Is it usable? Where can you get it? Important to remark that Devuan is usable, stable and under active development. * Future plans * Where does the project need help?/How to contribute? I'd recommend taking a look at this: https://www.slideshare.net/opennebula/opennebulaconf2015-112-the-status-of-devuan-project-alberto-zuin It's a bit outdated and had a different purpose, but it's interesting :) Am 13/08/2017 um 8:29 schrieb Enrico Weigelt, metux IT consult: > where exactly are you located ? lat: 50.8333 long: 12.9167 Just kidding, that's Chemnitz. I'm here and there, quite often in Saxony ;). -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan presentation at Chemnitzer Linux-Tage (Germany) 2018?
Thank you for posting it here Michael :). Am 12/08/2017 um 18:52 schrieb Michael Siegel: > There is a pretty big (2500-3000 visitors) Linux/FOSS event taking place > in Chemnitz (Germany) in March. It's called Chemnitzer Linux Tage > (Chemnitz Linux Days) and has been held annually since 1999. The > project's website can be found at > > https://chemnitzer.linux-tage.de. Also, this has a bit of a reputation in the "geek circles" in Germany. > I think it would be great if Devuan presented itself there. > > There are two possible ways of doing that: > > * Giving a talk of about 30 to 45 minutes and answering questions from > the audience for another 30 or 15 minutes respectively > > * Having a booth in the exhibition area of the building where people can > come by, inform themselves, ask questions, obtain installation media and > such > > I think it should be possible to have both if available manpower allows > for that. Maybe both is not quite necessary, you know how that goes, people come to you afterwards if they are interested. OTOH: if enough people end up volunteering, sure why not. > It would be best if a possible talk could be given in German language, > though that's not mandatory. The call for lectures will presumably be > out in mid-October. The website also has some notes for speakers > (https://chemnitzer.linux-tage.de/2017/en/programm/hinweise) as well as > for exhibitors > (https://chemnitzer.linux-tage.de/2017/en/programm/hinweise) that should > be considered. > > So, if anyone's interested, I'd be quite happy. I could help organizing > things. I'm actually interested here to see what our Elder Developers have to say. Maybe one of them can make it, that'd be a hit. As mentioned on IRC, I'm quite near and could lend a hand; my German is not perfect, but it's alright (as long as I don't have to understand extremely thick Chemnitzer accents :)). Let's see how much interest this gathers and what can be done from that, did you have any particular topic in mind? -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] donating a host
Am 12/08/2017 um 20:45 schrieb info at smallinnovations dot nl: > So is the intention to migrate dev1galaxy.org to this machines? Or > something like that? Then i am in! Already happened a few days ago ;) good to see it went unnoticed! (means it went smoothly) Here a small announcement about that: https://dev1galaxy.org/viewtopic.php?id=1532 -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I apologize, but I lost my email somehow with the, packages needed for openrc
Am 19/07/2017 um 16:57 schrieb zap: > openrc should be the default though runit should of course also > be available heh Changing people's default init system is how we got here. This is much saner: Am 19/07/2017 um 11:16 schrieb KatolaZ: > It is definitely desirable to have it among a set of pluggable > init systems, though. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Constitution and Social Contract WAS: Sexual politics and society
Am 19/07/2017 um 16:11 schrieb Rowland Penny: > Please stop with the rambling posts that make my eyes glaze over. they > also have little to do with Devuan. Thank you. As far as anyone here is concerned, I'm a female humanoid lizzard married to a human woman. And nobody should care. Just quickly pointing out to d1g's (almost) no code of conduct; which should probably apply everywhere: https://dev1galaxy.org/viewtopic.php?id=17 -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why did it take Devuan 2 years to replace systemd?
Hello Douglas, Am 09/07/2017 um 14:42 schrieb Douglas Guptill: > On Sat, Jul 08, 2017 at 11:13:16PM -0500, goli...@dyne.org wrote: > >> Here are some ideas: https://dev1galaxy.org/viewtopic.php?id=589 Eventually >> something will light your fire. :) > > OK, thanks for that. > >> Remember that a lot happens on irc too. > > I have installed irssi, and fired it up. But haven't yet had the > courage to join the devuan irc. Never used irc before. But I'll try > irc one day soon. Please don't doubt joining the #devuan channel, heck, join even the #devuan-dev channel. People are by far friendly (or direct-to-the-point informative, take it as lack of time for extreme politeness ;)). Even if you don't feel compelled to say hi at first, just lurking around can give you a sense of where things are moving and maybe give you some ideas of things that could be done but are not explicitly documented. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Amprolla: Another Network Outage.
Dear Linux, Am 06/07/2017 um 0:37 schrieb Linux O'Beardly: > Dear Devuan Community, > > We experienced another outage with the amprolla server today due to > severe weather. We've had severe storms with tornado force winds that > have taken down both our power and network grid. This is a separate > outage from the one that occurred yesterday that just effected our > network grid. Amprolla is now up and running and everything seems to be > in tact. I would offer apologies, but "acts of G(g)od(s)" are a little > out of my wheelhouse. On the upside, in the year and half I've been > hosting this server, I've only had three outages, all due to things > beyond my control. Thank you for you patience. Everything is back to normal now. Thank you and best wishes dealing with the elements! -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Amprolla Network Outage
Dear Linux, Am 04/07/2017 um 21:41 schrieb Linux O'Beardly: > We are currently experiencing a network outage that has left > amprolla.devuan.org <http://amprolla.devuan.org> unreachable. I've > spoken to the ISP and they stated the issue should be resolved within > the next 30 minutes, by 16:08 US EDT. Please feel free to reach out if > the issue persists past this time. As of now (19.30 UTC) Amprolla is reachable from a network level (e.g. ping works) but not from a protocol one. That means: - apt-get update fails when trying to reach amprolla.devuan.org - HTTP on amprolla.devuan.org times out - its SSH service does not reply for auth on port 22 (may be by design) One possible reason is that the software does not handle well network outages and is in an unkown state since yesterday (therefore needing a restart). Could someone take a look at it? -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd allows elevated access from unit files?
Am 04/07/2017 um 13:22 schrieb Joachim Fahrner: > > Next step probably will be to supersede unix user management and > integrate it into systemd :-D Ehem. There is no provision to delete users. https://www.freedesktop.org/software/systemd/man/systemd-sysusers.html -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd allows elevated access from unit files?
Am 03/07/2017 um 17:57 schrieb KatolaZ: > On Mon, Jul 03, 2017 at 10:45:29AM -0500, dev wrote: >> On 07/03/2017 10:40 AM, Evilham wrote: >> >> >>> That's the thing, we can do that :-) probably should, but the "right >>> way" (from a standards point of view) would be to actually allow those >>> names ^^ not to disallow them. So instead of modifying the way useradd >>> works, the way adduser works should be fixed (so, shadow). >> >> That was easy ;) Seems to be a flag for that. >> >> # adduser 0day --force-badname >> Allowing use of questionable username. >> Adding user `0day' ... >> Adding new group `0day' (1000) ... >> Adding new user `0day' (1000) with group `0day' ... >> Creating home directory `/home/0day' ... >> Copying files from `/etc/skel' ... >> Enter new UNIX password: > > When you think to have found something totally wrong in unix, you most > probably have not looked deep enough :) Yeah, there's also some env var that can be set. My point was taht the names are not allowed by default with some tools but with others they are and they are OK according to the standard, and that makes it quirky. Although I think it'd be better if they were allowed by default (consistency + standard compliance), TBH I'd be totally ok with not touching either adduser nor useradd; it's only an issue with disastrous decisions somewhere else. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd allows elevated access from unit files?
Am 03/07/2017 um 17:34 schrieb dev: > On 07/03/2017 10:17 AM, Evilham wrote: >> Am 03/07/2017 um 17:06 schrieb dev: >>> Would this be a good case to dis-allow ^0-9 by default but add a switch >>> to allow it? >> >> What's the case for disallowing those at all? names starting with a >> digit _are_ valid usernames. > > > useradd and adduser work differently. One allows it, the other does not. > Just thought 'why not make them work the same?'. That's all. That's the thing, we can do that :-) probably should, but the "right way" (from a standards point of view) would be to actually allow those names ^^ not to disallow them. So instead of modifying the way useradd works, the way adduser works should be fixed (so, shadow). > > Yes, seems to me it would be a patch with upstream, not Devuan. Most > likely this whole thing pointless since AD and SAMBA would break because > of changing it. :/ > I think allowing those previously disallowed users in shadow would not have a negative influence on AD / SAMBA integrations, maybe even a positive one. (Plus: better OS consistency). -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd allows elevated access from unit files?
Am 03/07/2017 um 17:06 schrieb dev: > Would this be a good case to dis-allow ^0-9 by default but add a switch > to allow it? What's the case for disallowing those at all? names starting with a digit _are_ valid usernames. It is an issue with systemd (and, to a different extent, shadow), we shouldn't deviate further from the standard because of that. Is this at all an issue in Devuan, given that we have no systemd? I think the fix would be more appropriate as a patch to shadow, so that the behaviour is consistent (e.g. usernames with dots and dashes or, yes, starting with a digit allowed). (sorry, had only replied to dev) -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
