On Sun 12/05/2024 at 22:52, Mario Marietto <[email protected]> wrote:

I want that the warp script is run everytime root is logged in,not more,not less.

The second half of this seems to do what you want

https://stackoverflow.com/a/39024841

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, May 13, 2024 at 01:48:25PM +0200, Mario Marietto wrote:

I wouldn't to login as root automatically,but I've realized that this
command :

echo 1 > /proc/sys/net/ipv4/ip_forward

work only if I'm root. It does not work using sudo. So,in the end I've
chosen to be root instead of a normal user that can use sudo.

Aha! Classic X-Y problem.

To do this with sudo, you can use a shell:

sudo sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'

However, this particular setting can also be done with sysctl:

sudo sysctl -w net.ipv4.ip_forward=1

Or if you just want the setting to be made permanent, edit the
/etc/sysctl.conf file, find the line that says:

# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1

and remove the # sign in front of net.ipv4.ip_forward=1 and then you
will never have to issue your command manually again.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Monnier (12024-05-13):

echo 1 > /proc/sys/net/ipv4/ip_forward

work only if I'm root. It does not work using sudo.

This doesn't sound right. Maybe you should investigate why you're
seeing this behavior, rather than work around the problem.

`sudo` *is* root.

No need to “investigate”, the answer is obvious: in

sudo foo > bar

… the > bar comes before the sudo.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

echo 1 > /proc/sys/net/ipv4/ip_forward

work only if I'm root. It does not work using sudo.

This doesn't sound right. Maybe you should investigate why you're
seeing this behavior, rather than work around the problem.

`sudo` *is* root.


Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:

.profile
will always be read as soon as the user logs in, no matter how. Through a terminal, a GUI, doesn't matter.

That's not correct. There are many different GUI login setups where
the .profile is never read.

That said, since this thread is specifically about *root* logins, GUI
logins may not be possible. It depends on which Display Manager and
Desktop Environment are in use. Many of them explicitly disallow direct
root logins.

So, ultimately it comes down to what the OP actually requires, and
what type of setup they use. If they only want this thing to happen
when root logs in directly on a console or ssh, then .profile may
indeed be the correct answer.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 13/05/2024 à 13:48, Mario Marietto a écrit :

If they only want this thing to happen when root logs in directly

on a console or ssh, then .profile may indeed be the correct answer.

Yes,I don't need to run xorg and a desktop environment,since warp-cli disconnect and warp-cli connect do not require them.
I wouldn't to login as root automatically,but I've realized that this
command :

echo 1 > /proc/sys/net/ipv4/ip_forward

work only if I'm root. It does not work using sudo. So,in the end I've
chosen to be root instead of a normal user that can use sudo.

For this it is sufficient to  use /etc/sysctl.conf

You find in the file shipped by debian


# Uncomment the next line to enable packet forwarding for IPv4 #net.ipv4.ip_forward=1

So you just have to uncomment and it will be done at boot time.


(You have the ipv6 equivalent in the same file, if needed)


--
Erwan David

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mario Marietto wrote:

If they only want this thing to happen when root logs in directly on a

console or ssh, then .profile may indeed be the correct answer.

Yes,I don't need to run xorg and a desktop environment,since warp-cli disconnect and warp-cli connect do not require them.
I wouldn't to login as root automatically,but I've realized that this
command :

echo 1 > /proc/sys/net/ipv4/ip_forward

work only if I'm root. It does not work using sudo. So,in the end I've
chosen to be root instead of a normal user that can use sudo.

If you run

sudo echo 1 > /proc/sys/net/ipv4/ip_forward

then the shell you are running it from will run "sudo echo 1"
and then try to put the output in that file. That fails because
the running process is owned by you, not root.

If you put the echo command into a script, and then run the
script with sudo, this will work.

-dsr-


then

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I was experimenting, and found this works:

sudo xterm -e "echo 1 > hello"

It created a file owned by root. But I found I was able to remove it
without being root even though group and world permissions were read
only.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dan Ritter (12024-05-13):

Mario Marietto wrote:> If you run

sudo echo 1 > /proc/sys/net/ipv4/ip_forward

then the shell you are running it from will run "sudo echo 1"
and then try to put the output in that file.

Other way around: the shell first tries to redirect the output to the
file and then (if it succeeds) runs sudo that way.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, May 13, 2024 at 02:53:18PM +0200, Nicolas George wrote:

[email protected] (12024-05-13):

That's like slicing your morning baguette with the chainsaw.

Worse than that, it will only work from an X11 environment. Certainly
not at boot.

The analogy to that would be that not many kitchens are equipped with
a chainsaw. Mine isn't ;-)

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZkIOlQAKCRAFyCz1etHa RjRLAJ0Y31pr3RWxW03uqc5Wh+SkAla3vgCfaW85VgJzd0HBbYRLYJsS5HVmfA8=
=DKLh
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 13/05/2024 à 14:36, Richmond a écrit :

I was experimenting, and found this works:

sudo xterm -e "echo 1 > hello"

It created a file owned by root. But I found I was able to remove it
without being root even though group and world permissions were read
only.

thats because sudo exceutes a xterm as root

then this xterm executes a shell (as root) and this root shell does the redirection.


--
Erwan David

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, May 13, 2024 at 01:36:23PM +0100, Richmond wrote:

I was experimenting, and found this works:

sudo xterm -e "echo 1 > hello"

That's like slicing your morning baguette with the chainsaw.

But if it works for you... hey :-)

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZkIL2QAKCRAFyCz1etHa RjQgAJ0cit6FEn0LtmcgUj5t1xrA9p85SQCcCEogWTpRMCi3JD0Diee4uOhzDnI=
=8zs2
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] (12024-05-13):

That's like slicing your morning baguette with the chainsaw.

Worse than that, it will only work from an X11 environment. Certainly
not at boot.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richmond wrote:

I was experimenting, and found this works:

sudo xterm -e "echo 1 > hello"

It created a file owned by root. But I found I was able to remove it
without being root even though group and world permissions were read
only.

The owner of a directory can delete any file in it.


-dsr-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Erwan David <[email protected]> writes:

Le 13/05/2024 à 14:36, Richmond a écrit :

I was experimenting, and found this works:

sudo xterm -e "echo 1 > hello"

It created a file owned by root. But I found I was able to remove it
without being root even though group and world permissions were read
only.

thats because sudo exceutes a xterm as root

then this xterm executes a shell (as root) and this root shell does
the redirection.

Yes, but why did it allow me to delete the file? I was not root
then. Try it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richmond (12024-05-13):

sudo bash -c "echo 1 > hello"

Use sh for that.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 13/05/2024 à 15:03, Richmond a écrit :

Erwan David <[email protected]> writes:

Le 13/05/2024 à 14:36, Richmond a écrit :

I was experimenting, and found this works:

sudo xterm -e "echo 1 > hello"

It created a file owned by root. But I found I was able to remove it
without being root even though group and world permissions were read
only.

thats because sudo exceutes a xterm as root

then this xterm executes a shell (as root) and this root shell does
the redirection.

Yes, but why did it allow me to delete the file? I was not root
then. Try it.

as said Dan Ritter : the owner of the directory can delete any file
inside the directory.

(see a directory as a special file containing pairs (name,file place on
the disk). Deleting a file is just removing the pair from the directory,
thus it is editing the directory, not the file.

--
Erwan David

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

<[email protected]> writes:

On Mon, May 13, 2024 at 01:36:23PM +0100, Richmond wrote:

I was experimenting, and found this works:

sudo xterm -e "echo 1 > hello"

That's like slicing your morning baguette with the chainsaw.

I do that too.

But if it works for you... hey :-)

Cheers

This also works:

sudo bash -c "echo 1 > hello"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mario Marietto (12024-05-13):

The command iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE doesn't work if invoked as a user,it says "you must be root". So,as
user,the script seems to be working fine like this :

function jumpto
{
label=$1
cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
eval "$cmd"
exit
}

You seem to be investing a lot of effort into a fragile solution to
emulate a deprecated execution control primitive.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, May 13, 2024 at 09:17:31AM -0400, Greg Wooledge wrote:

On Mon, May 13, 2024 at 02:03:59PM +0100, Richmond wrote:

sudo xterm -e "echo 1 > hello"

Yes, but why did it allow me to delete the file? I was not root
then. Try it.

Because you have write permission on the *directory* that the file is in.

Removing (unlinking) a file is an operation that modifies a directory,
not the file itself. You don't need write permission on the file. Just
the directory.

Unless the directory has the sticky bit set (e.g. /tmp).

(For completeness: I know you know that).

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZkITegAKCRAFyCz1etHa RkrZAJ424y5Fospajw+sSuOx0Qni9n1jHACcCPLq5QNZ/QWUcLZnty5bbrPEn/U=
=UHRY
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

echo 1 > /proc/sys/net/ipv4/ip_forward

This doesn't sound right. Maybe you should investigate why you're

No need to “investigate”, the answer is obvious: in

You don't need to, but I definitely think he does. 🙂


Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, May 13, 2024 at 02:03:59PM +0100, Richmond wrote:

sudo xterm -e "echo 1 > hello"

Yes, but why did it allow me to delete the file? I was not root
then. Try it.

Because you have write permission on the *directory* that the file is in.

Removing (unlinking) a file is an operation that modifies a directory,
not the file itself. You don't need write permission on the file. Just
the directory.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

You don't need to, but I definitely think he does. 🙂

^^

[ Oh, bias, when will you leave me alone? ]


Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge:

On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:

.profile

Sorry, dumb question: Depending of the shell, the user is using (let's say, he will use bash), can the script not be added into ~/.bashrc?

If yes, second dumb question: Coiuld it be ANY script or command?
(also running as non-rootuser, like adding "runuser -u myuser command_whatever").

Just some thoughts....

Best

Hans

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote:

Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge:

On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:

.profile

Sorry, dumb question: Depending of the shell, the user is using (let's say, he
will use bash), can the script not be added into ~/.bashrc?

Yes. Consult your shell's manual. And it will also depend on whether
it is considered to be a "login shell". And on a couple of other
factors.

If yes, second dumb question: Coiuld it be ANY script or command?
(also running as non-rootuser, like adding "runuser -u myuser command_whatever").

Root can do this, yes.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZkJA1QAKCRAFyCz1etHa RmCwAJ9PT92ubxiLgn66kMAxw//zEtqicQCdEGVKY6iTQKfdbDsUKbFxPSZcQCs=
=S9Q9
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Nobody has yet applauded this glorious implementation
of the 1960s GOTO statement in *Bash*?!

* Mario Marietto <[email protected]> [24-05/13=Mo 13:37 +0200]:

function jumpto
{
label=$1
cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
eval "$cmd"
exit
}

Anyway, Marietto, you've got two typi:

mid :

That should be "mid:".

jump foo

That should be "jumpto foo".

Once you've got your root-login script working, I hope you
move on to implementing a complete open-source PL/I compiler.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mario Marietto <[email protected]> writes:

There is still a problem. If I login automatically as user and inside
the script I do this :

sudo iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE

it asks me for the password (don't know why it didn't before) but I
can't issue a password,because the script inside the vm should work automatically and should be hidden between the FreeBSD processes.

Why does it need to be executed at login? Maybe you could get root's
crontab to execute it. A script could detect when a user is logged in.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote:

Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge:

On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:

.profile

Sorry, dumb question: Depending of the shell, the user is using (let's say, he
will use bash), can the script not be added into ~/.bashrc?

The context has been snipped out. The context for this was "OP is trying
to run a command when root logs in". The method of login was not stated.
First responder said ".profile works for every method of login". I said
that this is incorrect: it doesn't work for many GUI login setups.

In those same GUI login setups, .bashrc is *also* not read when the
user logs in. None of the shell startup files are read at all.

All of this is a tangent to the actual problem, though.

If yes, second dumb question: Coiuld it be ANY script or command?
(also running as non-rootuser, like adding "runuser -u myuser command_whatever").

We're several layers deep into an X-Y problem here. The *actual* problem
is that the system's networking configuration is not correct/complete.

The *workaround* is that the OP is logging in and running commands to
change the networking configuration temporarily.

The question resulting from the workaround (the Y in the X-Y) was "How
can I automate these commands that I keep having to type?"

The proper question should have been "How can I fix my system's networking configuration permanently?"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon 13 May 2024 at 21:18:30 (+0200), Mario Marietto wrote:

On Mon, May 13, 2024 at 9:05 PM Greg Wooledge <[email protected]> wrote:

On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote:

Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge:

On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:

.profile

Sorry, dumb question: Depending of the shell, the user is using (let's

say, he

will use bash), can the script not be added into ~/.bashrc?

The context has been snipped out. The context for this was "OP is trying to run a command when root logs in". The method of login was not stated. First responder said ".profile works for every method of login". I said that this is incorrect: it doesn't work for many GUI login setups.

In those same GUI login setups, .bashrc is *also* not read when the
user logs in. None of the shell startup files are read at all.

All of this is a tangent to the actual problem, though.

If yes, second dumb question: Coiuld it be ANY script or command?
(also running as non-rootuser, like adding "runuser -u myuser command_whatever").

We're several layers deep into an X-Y problem here. The *actual* problem is that the system's networking configuration is not correct/complete.

The *workaround* is that the OP is logging in and running commands to change the networking configuration temporarily.

The question resulting from the workaround (the Y in the X-Y) was "How
can I automate these commands that I keep having to type?"

The proper question should have been "How can I fix my system's networking configuration permanently?"

The context has been snipped out....

nope. Read well what I said on my first post :

*[Forgot to say that I switched boot target to text with this command :*

*sudo systemctl set-default multi-user.target]*

What does this mean for you ?

To me, it means just one more change while trying to get your
networking to work. Your OP finished with "It does not work and anyway
it does not seem to be what I want..." and "I suspect that the
solution is easier than what I'm trying to do...". Again, to me,
that suggests that after settling on a better, permanent solution
to your problem, you would roll back the other changes that you
made along the way.

The context is that I was not using any
desktop manager.

My understanding of this statement is that "the context" is what
is described in your OP. As you said you "switched boot target to
text", I would assume you originally had a different target, likely
a DM, and that you might revert back to it after solving the problem.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, May 14, 2024 at 08:09:18AM +0200, Mario Marietto wrote:

Nobody can show a different way,a modern way, for creating my script ? Why did I feel so comfortable by recreating the 1960s GOTO statement in Bash ?

I think your style is too alien to most of the people here to
make them feel their time is worth trying to wrap their heads
around it (I just got a rough feeling on how it works, asked
myself "Why?" and went on).

You'll have to go it alone if you chose such an idiosyncratic
style, it seems.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZkMIrAAKCRAFyCz1etHa Rp7YAJ9Wz0oVL3XjqitMkpr2U5L/WCmzmQCdFMtVpa0SEqT2PUIsjZCz/YqQeBM=
=xJfh
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, May 14, 2024 at 08:09:18AM +0200, Mario Marietto wrote:

Nobody can show a different way,a modern way, for creating my script ? Why did I feel so comfortable by recreating the 1960s GOTO statement in Bash ?

I have absolutely no clue what you're trying to do or why you're trying
to do it, but I *promise* you, whatever you think you're doing, you
have NOT recreated a GOTO statement in bash.

You showed a function. Functions can be called. This is NOT the same
as issuing a GOTO command, because once the function returns, control
flow resumes from the point where it was called.

Bash (and sh, on which bash is based) explicitly chose not to have a GOTO statement in its language. The authors chose instead to use the control primitives that are collectively known as "structured programming"
(if, while, for, functions).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, May 14, 2024 at 01:10:05PM +0200, Mario Marietto wrote:

Your answer does not help me to understand how to use a "structured programming / if , while, for, functions" for the specific task that I want to achieve.

What task is that?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, May 14, 2024 at 02:51:17PM +0200, Mario Marietto wrote:

I've installed the Cloudflare gateway on Debian as a vm because I can't do
it directly in FreeBSD. But I want to be covered even when I use FreeBSD.
The script that I wrote forward the Cloudflare "VPN" from Debian to FreeBSD,so from outside my IP will be cloudFlared.

Disclaimer: I know nothing about Cloudflare.

So you wrote a bash script. I will assume this script does what you
want it to. You type its name to run it, or you have it set up to run
at boot time, or you have it set up to run at login time, or via a
cron job, or via a DHCP dhclient enter/exit hook....

Where does the GOTO come in? Do you think your script does something internally which mimics a GOTO in some way? Or that it *should* do that?

Why would you need a GOTO to do whatever networking configuration steps
the script does? Lacking any knowledge of Cloudflare, I'm imagining
that the script simply performs a sequence of commands, in a linear order, without any branching or looping or jumping around.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)