The officially official Devuan Forum!

You are not logged in.

#1 Re: Off-topic » Learning Linux » 2020-07-31 14:11:15

The best way is to start pulling features from your system. Challenge yourself just to use the command line to solve simple problems.

My two cents wink

#2 Hardware & System Configuration » Nonpersistent and encrypted image » 2020-06-13 15:33:46

siva
Replies: 2

I'm wondering if the Linux desktop can be set up to mimick platforms like Android, in terms of their security model (and not their spyware).

Tools like dd can already "flash" a live image to a drive, like sda. This allows one to use a nonpersistent environment, which has its own cases and uses.

My thought was, if the squashfs could be encrypted, and isolinux could decrypt it at boot, then one could have a secure nonpersistent environment. There's a rather old ubuntu article about this, but the script is pretty convoluted, and it uses grub as opposed to isolinux. (https://askubuntu.com/questions/1041916 … om-live-cd)

So, I wanted to know if anyone has accomplished this kind of thing, and if so, how?

#3 Re: Off-topic » wifi tool (wefe as a C program) » 2020-05-25 01:25:07

Head_on_a_Stick wrote:

...the README.md which says to run all three steps as root.

Fixed.

Btw you seem to have broken your Makefile the last commit by adding spaces around the = in the PREFIX, FOLDER & CONFIG lines.

An uninstall target in the Makefile would also be nice even though it's only a folder and a single binary.

Fixed.

Another error with the new version...space in my SSID smile

Definitely fixed. (It wasn't pointing to the def.config_file path.)

Sorry to be a pain here, I'm sure I'm doing something wrong.

You're not --- the code was the pain ^_^

#4 Re: DIY » Linux ports of OpenBSD's ksh » 2020-05-24 22:40:57

golinux wrote:
siva wrote:

how tf did I miss this?.

Because you're barely a shadow here these days.  You have been missed!

^_^

Head_on_a_Stick wrote:

Statically-linked version here...

I tried following the link and it said the file isn't found sad

#5 Re: Off-topic » wifi tool (wefe as a C program) » 2020-05-24 22:25:42

Thanks, I'm glad you like it smile And thanks for the feedback. Here's some followup:

I edited config.h and substituted wlp4s0 in place of wlan0 then ran...

That one's on me. The scanner library wasn't accepting the data type for the def.iface. To test, I just dropped "wlan0" directly in that function. Then I forgot to remove it. That should be fixed now.

I also modified the wpasupplicant driver list (idk what others are popular and might be in there as well), and changed iwconfig -> iw ^_^

It is considered bad practice to run the make command as root, I would prefer to build the package under my normal user and only invoke root privileges to actually install the package (as demonstrated above).

Is the suggestion to prevent root from running anything other than make install? I'm confused.

Finally, the removal-of-plaintext-password idea is legit. Not sure how this will look in C, but I went ahead and added a config option in the meantime, just as a reminder.

#6 Off-topic » wifi tool (wefe as a C program) » 2020-05-23 14:40:58

siva
Replies: 5

My wifi script is now a C program. It was a way to practice C for a course.

The biggest caveat is there's no config right now. That means, you'll have to rebuild it if your wireless card identifies as anything other than wlan0. Not sure if it would be better to rebuild for a different wireless interface, pass it as an argument, what the standard is for C config files, etc.

Anyways.

Love it. Hate it. Give valuable critique about it.

https://gitlab.com/souperdoupe/thom-uti … aster/wefe

#7 Re: DIY » Linux ports of OpenBSD's ksh » 2020-05-23 14:35:18

how tf did I miss this?

Thanks hoas.

#8 Hardware & System Configuration » What's your working apulse configuration? » 2020-05-22 15:31:49

siva
Replies: 0

I'm just looking for a working example that I can dissect.

(This is a vanity ask with, unfortunately, a time constraint.)

#9 Re: Devuan Derivatives » ThomOS - the new outrageous devuan-based switchblade OS » 2020-05-05 14:39:35

Your favorite lightweight OS just got an update:

https://sourceforge.net/projects/thomos … homos-0.2/

Major changes include

- Script to automate builds. (This is making my life crazy easy.)
- Fixed the openbox menu links
- Changed some default programs
  - Browser: netsurf
  - Editor: geany
  - File manager: xfe
  - Terminal: urxvt
- Fixed an issue where permissions had to be set in an insecure way for a user to boot X (Shoutout once again to FSR for saving the day)
- Pulled the fanenza-darkest icons without the entire ~118mb package
- Minor cosmetic changes to the gtk2/3 theme
- Screenshots! https://sourceforge.net/projects/thomos/

#10 Re: Devuan Derivatives » Hey siva! » 2020-04-14 16:10:53

It looks like the emails just took awhile to arrive to the requested account. Then they landed in my spam folder.

But, it's updated now. All is well with the universe.

#11 Re: Devuan Derivatives » Hey siva! » 2020-04-14 04:44:08

Sent you an email. Tl;dr, need to update email but can't access the account currently on file.

#12 Re: Devuan Derivatives » Hey siva! » 2020-04-14 04:03:16

I used the "change email address" feature in my profile. Said something about RRQ needing to approve it.

#13 Re: Devuan Derivatives » Hey siva! » 2020-04-14 03:22:37

Thanks! Thought I updated that like last year.

Awaiting RRQ.

#14 Re: Devuan Derivatives » [ ARM ] Desktop » 2020-01-31 16:33:11

tuxd3v wrote:

Devuan ARM desktop version

I think a lot of users just flash the devuan base and then install a wm/desktop, if they want one at all.

If I had a bunch of ARM boards lying around, I could see myself writing a tool for creating a small, flashable image.  That way, I could control those parameters before I even boot the board.  And, the image would be exactly what I want, not what you think I want.

The stali project is also worth looking into.  Its vision honed in on Raspberry Pis specifically and static-linked libraries.  I'm not sure if that's in the scope of your vision, but I thought it was a great idea.

Keep us posted on your progress.

#15 Re: Devuan Derivatives » ThomOS - the new outrageous devuan-based switchblade OS » 2020-01-22 16:47:18

Altoid wrote:

Hello:

stanz wrote:

... install pcmanfm or remove its non-working menu entry?
... other menu items failed.

Has anything else happened with this Derivative?

It looks really great (reminds me of my favourite # !) but to be a switchblade OS it needs to have a fully functional file manager (or at least MC installed) and some sort of auto network configuration or scripts to get things running.

Otherwise it's sort of crippled.

Any news?

Thanks in advance,

O.

@Altoid: thanks for following up.  I'm glad to hear you like the appearance.

On the topic of development: I finally scraped together enough money to buy a VM server, where I'm currently developing.  Likewise, I will probably just set up lighthttpd to streamline downloads and avoid external sites like sourceforge. I've lived without nonwork internet for about a year and finally have reliable connectivity again.

The next release is semi ready to go -- I'm building it from scratch.  I've spent awhile upgrading the tools -- particularly the wifi manager.  Dependency bloat has impeded many of my decisions in terms of components like a file manager, but I share your belief that something like MC should absolutely be installed.

There have also been other little surprises about the base I released last year -- particularly, things like, I completely forgot to install things like lsusb.  Really, really crticial components for debugging and fixing a system.  I'm trying to find a procedure to avoid this.

I'm also working on a way to automate the debootstrap->chroot->install->configure process.  It ended up more ambitious than I realized.  I've spent much of this year learning things I didn't realize could be done.

You can see progress on the thom-utils gitlab, particularly the "beta" folder.  (In truth, the OS is just a proof of concept for the tools, so looking at the project that way may make more sense.)  You can also view my post history for some further insights on changes.

#16 Re: Devuan » make TDE desktop default and sothen devuan as different distro option » 2020-01-22 16:39:37

"If only there were a minimal version of devuan, where users could choose which desktop environment or window manager they wanted to use..."

For the record, if XFCE ever gets tanked or (even more) bloated, I'm all about a console-only devuan as the main base.

Then again, I'm also a psychopath when it comes to minimalism.  *places two cents in the jar*

#17 Re: Hardware & System Configuration » Passwordless root execution in scripts » 2019-12-13 03:57:21

jaromil wrote:

This software may be useful for your use-case: https://sup.dyne.org/

There is also a more minimalist (suckless) version that parazyd maintains here http://parazyd.org/git/sup/log.html

This looks great.  Can't wait to try it out.  Thanks, jaromil.

UPDATE: Weird, parazyd's version won't run the command as root (setgid failed) unless "sudo" is prepended.  But, it looks liket the permissions are set correctly.

-rws--x--x 1 omega staff 763024 Dec 13 05:22 /usr/local/bin/sup*

#18 Other Issues » Adjusting brightness in C » 2019-12-13 03:55:27

siva
Replies: 3

I have a shell script that updates brightness using echo [number] > /location/of/brightness. It works okay when it's run as root. Also, as root, I can adjust the brightness value using an editor like nano.

A few minutes ago, I tried to translate this into a simple C program.  It compiled fine.  However, when I tried running the program as root, it gave a "Segmentation fault" as the result, and did not change the brightness.

Can anyone offer any pointers?

Here's the code:

#include <stdio.h>
#include <fcntl.h>	// Use "open"
#include <unistd.h>	// For "close"

int main() {
	// Open the brightness file.
	FILE *fp = fopen("/sys/class/backlight/acpi_video0/test", "w+");
	// Adjust brightness value.
	fprintf(fp, "5");
	// End.
	fclose(fp);
	return 0;
}

#19 Off-topic » devuan on BuyVM » 2019-12-10 20:38:35

siva
Replies: 1

As a point of bragging rights, I'm thrilled to learn that devuan has a presence on BuyVM:

devuan.png

This is perfect because now I can develop my OS around my absurd time constraints and schedule. 

I was actually among the first to donate to devuan back in 2014.  It's awesome to know that this project has gained so much momentum in the last five years.  I'm also proud to have played even an insignificant role.

#20 Re: Hardware & System Configuration » Passwordless root execution in scripts » 2019-12-10 20:18:31

Thanks, I will give this a read.  This is all uncharted territory for me.

#21 Re: Off-topic » ladies, gentlemen and whomever else: your fifth freedom... » 2019-12-10 20:17:25

HevyDevy wrote:
golinux wrote:

Soon you will not be able to choose not to run systemd.  Systemd is "capturing" the GNU-Linux "commons" that we have shared for decades through a web of hard dependencies. The only choice will be not to use GNU-Linux.

How soon ?

P sure there isn't a set date, but as a general trend, a lot of software will move with the opinion of the "mothership distros."  Alternatives will only be at the mercy of the larger bastions, like slackware and gentoo.  But, if those projects shut down, buy-in to systemd, or just don't find the battle worth it, we'll be locked.

I'm of the belief that this probably won't happen, but only because there is so much pushback from the BSDs and Slack/Gentoo.

On the other hand, I am very concerned about SOIC hardware fucking over the open-source ecosystem by design.

#22 Re: Hardware & System Configuration » Passwordless root execution in scripts » 2019-12-10 01:06:20

I think what I'm looking for might be setuid: something like root:netdev ownership and 4750 permissions.  It looks like this is a contentious solution for scripts, as opposed to binaries.

I read that if someone were to compromise the setuid binary, it would widen the attack surface.  Then again, to do something like that, I imagine they'd need root access -- so, I'm not sure I understand or appreciate the difference.

#23 Re: Devuan » Debian considering going systemd init only » 2019-12-09 14:52:58

HevyDevy wrote:

Im old school though, we will eventually get left behind and overtaken with tech that is shiny and "progressive"...

You'd think so, but then you've got people like me majoring in CSE.

#24 Re: Off-topic » Marginalizing systemd » 2019-09-06 18:00:26

pj1967 wrote:

Are there ways to strip it down to nearly nothing, and then call my own "rc.local" scripts to start the few things that I want running?

It may be fruitful to play around with RHEL in a VM.  You can circumvent init and a service manager (or don't use a service manager at all) pretty easily.  I posted a couple things a few weeks ago that you might find useful.

I don't know your role, why your customer wants RHEL, or how it will be used.  When we want to steer a customer to a better alternative, we usually just let them tell us why they want "their" way, and explain the issues with their thinking.  Then, we suggest a better route.

Based on its stats, how likely is it that RHEL7, which we know is a farcry from RHEL6, will run well on it?  How many more hours will be charged to maintenance?  I don't need an answer, but these are issues with tangible consequences for a customer.

#25 Documentation » Installing sinit on devuan [alpha] » 2019-08-24 15:03:25

siva
Replies: 0

This post should offer some pointers if you want to try out suckless.org's init on a devuan system.  It is the first step in a larger overhaul with my project spin.  This alpha-quality documentation, and I intend to provide updates when I can.  Please post your wisdom to help expand it.

I find sinit attractive becuase it's quick and builds quickly.  For a nonpersistent live system, this is very desirable.  I also don't care about having a service manager on a drive-by operating system.

I'm going to proceed with a yet-unverified claim: that this will work for any devuan system.  If anyone wants to prove this right or wrong, please post your results.  Unfortunately, my bandwidth and time are limited at the time of writing.

Requirements

  • * A devuan image with sysvinit preinstalled (I used thomos, which is built from an ascii debootstrap)
    * Suckless.org's init
    * A test environment or virtual machine (I used virtualbox)
    * sysvinit scripts in rcS.d
    * gcc and make installed
    * git (optional)

Installing the base system

This is probably the sloppiest (but easiest) way to test the init's functionality.

- Install devuan or devuan-like image in your test environment.
- Chroot into your system.
- Set up your network.  In virtualbox: dhclient eth0
- If needed, update packages and install gcc, make, and git (if that's how you're getting the source): apt-get update && apt-get install gcc make git
- Grab the sinit source: git clone git://git.suckless.org/sinit
- Build the package: cd sinit && make && make install (by default, it installs to /usr/local/bin)
- Replace sysv's init: cp /sbin/init /sbin/init.sysvinit && cp /usr/local/bin/sinit /sbin/init
- At this point, you can remove sysv packages if you want.
- Use an editor to create the file /bin/rc.init (My example is used below):

#!/bin/sh
echo "Loading devuan with sinit."
# At bare minimum, boot to a shell.
/bin/bash
exit 0

- I made it executable, but I'm not sure if it's necessary to do so: chmod +x /bin/rc.init
- Exit the chroot and reboot the test system
- At boot, you should see the "Loading devuan with sinit" message, and a bash prompt should appear.

Getting Xorg

Using the rc.init file we created, you should boot to a root console.  Your system is read only.

The scripts in rcS.d have some missing links to getting Xorg up and running.  Right now, I could not tell you what they are doing.

- Make sure /tmp has write premissions.  One way to accomplish this is to remount the filesystem as read/write: mount -o remount,rw /
- Open /bin/rc.init in an editor.
- Add the following code before /bin/bash:

# Borrowing lingering SysV scripts.
# This method is sloppy and pays no mind to what each script is doing.
for script in /etc/rcS.d/*; do 
    sh $script start;
done

- To run Xorg as a user (example, the user "thomos"): su thomos
- Make sure .xinitrc executes an environment (example, "exec openbox-session")
- Run startx

Screenshot

Final product, based on 2019-08-24 procedures:
2019-08-24-142501-1021x633-scrot.png

Board footer

Forum Software