progress
doas
progress | doas | |
---|---|---|
10 | 29 | |
8,195 | 725 | |
- | - | |
5.2 | 4.6 | |
7 months ago | 10 days ago | |
C | C | |
GNU General Public License v3.0 only | BSD 2-clause "Simplified" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
progress
- Ask HN: What is the most practical tool/website you discovered on Hacker News?
- Xfennec/progress: Linux tool to show progress for cp, mv, dd, ... (formerly known as cv)
- Linux tool to show progress for cp, mv, dd
-
Make a "Boot and Nuke" bootable usb drive
You could use this: https://github.com/Xfennec/progress
- Pipe Viewer
-
The Wrong Way to Switch Operating Systems on Your Server
`progress` (https://github.com/Xfennec/progress) and similar can be very helpful too depending on the backup utilities being used (in my case often involving rsync) even if the processes normally have everything set to quiet so no progress information is automatically forthcoming.
-
Is it better to use cat, dd, pv or another procedure to copy a CD/DVD?
pv's progress display is very useful in many contexts, it has been one if the first things I make sure is installed on a new system for years, though I have recently come across https://github.com/Xfennec/progress which is brilliant for some times when pv is not an option or when you want to watch the status of several things which aren't convenient to arrange together via tmux/byobu. Or just for when you forget to use PV and don't want to cancel to change the command.
-
Week 2: Improving real-time monitoring with more more metrics!
this is awesome! can you add support for progress
doas
-
Doas – dedicated OpenBSD application subexecutor
OpenDOAS has actually had the OpenBSD-specific code removed, and replaces some of the doas mechanisms that rely upon OpenBSD to work with sudo-like flag files and suchlike.
There are, moreover, 2 ports of doas to other systems. OpenDOAS is one. Jesse Smith's https://github.com/slicer69/doas is the other. The latter retains the OpenBSD-specific code, and is the more portable of the two at the expense of only doing everything that the tool is capable of when actually built on OpenBSD.
-
Testing the memory safe Rust implementation of Sudo/Su
There's also a straight port of doas:
https://github.com/slicer69/doas/
However unlike sudo and opendoas this does not implement the persist feature on not-OpenBSD.
-
Doas Mastery (2019)
As mentioned elsewhere, this is because it relies upon a kernel mechanism that Linux simply does not have, and fixing this involves fixing Linux.
To which I add that it is important not to conflate Jesse Smith's doas, the portable doas that has code for different operating systems including OpenBSD, with Duncan Overbruck's OpenDoas, the "open" doas that is tied to Linux has has had the code for other operating systems removed and mechanisms copied in from sudo for things like timeout flag files.
* https://github.com/slicer69/doas
* https://github.com/Duncaen/OpenDoas
-
Don't abuse su for dropping user privileges (2015)
TIOCSTI is irrelevant. When one is dropping privileges, in a system cron job or in a process supervised by one's favourite service management system, there is no terminal involved. TIOCSTI simply doesn't enter into the picture at all.
Only when one is in a terminal login session and using su to elevate / add privileges, does TIOCSTI become relevant. But no-one here is saying not to use su to add privileges.
People blame su, sudo, and (as the person at https://github.com/slicer69/doas/issues/110 did) doas for this feature of operating system kernels. The right thing to do with TIOCSTI it to just eliminate it from the kernel. OpenBSD did back in version 6.
Sadly, the argument from Alan Cox, Linux developer, when this was proposed years ago was that it should stay in Linux, and all of the programs like su, sudo, and doas should have even more things to do in the parent process that sticks around, namely pump I/O to and from a controlling pseudo-terminal that su/sudo/doas sets up for the shell subprocess, breaking (as the maintainer of OpenDoas pointed out) the long-standing notion that the child processes belong to the same terminal session and share things like a single getlogname() with the login shell.
6 years after https://www.openwall.com/lists/kernel-hardening/2017/05/10/3... and https://www.openwall.com/lists/oss-security/2017/06/03/9, there is no sign of anyone doing anything of the sort in any su or doas implementation. (It was briefly in one su implementation, but taken out in 2017 for being a "stupid hack": https://github.com/util-linux/util-linux/commit/23f75093264a...)
Fortunately, some six months ago Linux developers finally made TIOCSTI removable and the right course of action is available to those that want it: https://lore.kernel.org/lkml/20221228205726.rfevry7ud6gmttg5...
-
Linux tool to show progress for cp, mv, dd
It's more likely that this is the entire "upstream downstream" development model in action again.
There are vast numbers of improvements to softwares that never get sent to the places where they will do the most good (or at least have a proper record of why they were rejected by their authors). A quick perusal of the bug trackers of Debian or Ubuntu will reveal tonnes of local patches that the original authors of the softwares often never even hear about.
Things don't "stick" often times simply because they get lost.
I was looking at something like that just the other day. Here's a bug report that describes a problem with "doas" not opening the controlling terminal to do its authentication dialogue. This is actually a problem with a package named LinuxPAM, and doesn't occur when "doas" uses OpenPAM or BSD Auth. It's LinuxPAM that's where the code in question is. Fixing LinuxPAM would improve the lives of everyone that uses LinuxPAM, because the behaviour of not allowing standard input through in a command pipeline is not confined to "doas" but affects everything that uses LinuxPAM to do login authentication.
But time and again stuff like this languishes in the wrong place, for years and decades.
* https://github.com/slicer69/doas/issues/17
-
Installing Docker and a media stack (Plex, *arrs, download clients, elaborate script) [Text]
Now that you have your headless Debian server running, and you’ve installed doas and Webmin, we’ll get things rolling by installing:
-
Installing a headless Debian (Linux) server for file storage and other cool stuff [Text]
Now, let’s replace “sudo” with “doas”. Type git clone https://github.com/slicer69/doas.git to download doas from Github.
-
Trying to install doas and other programs
You can compile it from source : https://github.com/slicer69/doas
- trouble compiling doas
-
DOAS
It's also the one with a history of critical security issues because the maintainer has no idea what he's doing porting OpenBSD code to Linux.
What are some alternatives?
appmetrics - Node Application Metrics provides a foundational infrastructure for collecting resource and performance monitoring data for Node.js-based applications.
sudo - Utility to execute a command as another user
harbormaster
OpenDoas - A portable fork of the OpenBSD `doas` command
nocache - minimize caching effects
runas - An alternative to sudo and doas written in Rust
nagios-plugins-linux - :penguin: Nagios-compatible Plugins for Linux
please
nixos-infect - [GPLv3+] install nixos over the existing OS in a DigitalOcean droplet (and others with minor modifications)
rudo - A toy sudo clone written in Rust
advcpmv - A patch for GNU Core Utilities cp, mv to add progress bars
sudo-rs - A memory safe implementation of sudo and su.