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 the
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 ?
On Mon, May 13, 2024 at 6:30 PM Will Mengarini wrote:
> Nobody has yet applauded this glorious implementation
> of the 1960s GOTO statement in *Ba
On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote:
> Maybe someone here knows how the ownership of these files for Dovecot needs
> to be in order to work, as various distributions of Dovecot packages seem
> to use different users:
> I'd like Dovecot not to log into syslog, but to dedicated fi
On 5/12/24 21:30, David Wright wrote:
On Sun 12 May 2024 at 21:10:16 (-0700), Paul Scott wrote:
On 5/9/2024 1:59 PM, Charles Curley wrote:
On Thu, 9 May 2024 09:32:32 -0700 Paul Scott wrote:
The error I'm getting is during "Install base system." The only way
I knew to save the log was with
On Mon, May 13, 2024 at 08:37:16PM +0200, Erwan David wrote:
> Le 13/05/2024 à 19:45, Stefan Monnier a écrit :
[...]
> > % sudo zsh -l
> > # echo 1 > /proc/sys/net/ipv4/ip_forward
> > # ^D
> > logout
> > %
> >
> > 🙂
> >
> >
> > Stefan
> >
> >
> sudo -i will
On 14/5/24 04:16, Richard wrote:
Maybe someone here knows how the ownership of these files for Dovecot
needs to be in order to work, as various distributions of Dovecot
packages seem to use different users:
I'd like Dovecot not to log into syslog, but to dedicated files.
Therefore I've create
On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote:
> Maybe someone here knows how the ownership of these files for Dovecot needs
> to be in order to work, as various distributions of Dovecot packages seem
> to use different users:
> I'd like Dovecot not to log into syslog, but to dedicated fi
On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote:
> May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: to=,
> > relay=local, delay=3.2, delays=1.9/0.29/0/1.1, dsn=4.3.0, status=deferred
> > (temporary failure. Command output: lda(user): Error:
> > net_connect_unix(/run/dovecot/stats-w
Maybe someone here knows how the ownership of these files for Dovecot needs
to be in order to work, as various distributions of Dovecot packages seem
to use different users:
I'd like Dovecot not to log into syslog, but to dedicated files. Therefore
I've created the directory /var/log/dovecot and to
yeah at the beginning i used xorg + xfce but then i realized that i did not
need them,so the context became the textual mode.
Il lun 13 mag 2024, 21:52 David Wright ha
scritto:
> On Mon 13 May 2024 at 21:18:30 (+0200), Mario Marietto wrote:
> > On Mon, May 13, 2024 at 9:05 PM Greg Wooledge wrot
On Mon 13 May 2024 at 21:18:30 (+0200), Mario Marietto wrote:
> On Mon, May 13, 2024 at 9:05 PM Greg Wooledge 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, Richa
---> 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 ? The context is that I was not using any
desktop manage
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),
Le 13/05/2024 à 19:45, Stefan Monnier a écrit :
$ su -
Password:
# echo 1 > /proc/sys/net/ipv4/ip_forward
# ^D
logout
$
I don't need no stinkin' sudo :-)
And if you only have `sudo`, but not the root password, of course:
% sudo zsh -l
# echo 1 > /proc/sys/net/ipv4/ip_forward
# ^
On Mon, May 13, 2024 at 01:45:40PM -0400, Stefan Monnier wrote:
> > $ su -
> > Password:
> > # echo 1 > /proc/sys/net/ipv4/ip_forward
> > # ^D
> > logout
> > $
> >
> > I don't need no stinkin' sudo :-)
>
> And if you only have `sudo`, but not the root password, of course:
>
> % sudo zsh -l
>
> $ su -
> Password:
> # echo 1 > /proc/sys/net/ipv4/ip_forward
> # ^D
> logout
> $
>
> I don't need no stinkin' sudo :-)
And if you only have `sudo`, but not the root password, of course:
% sudo zsh -l
# echo 1 > /proc/sys/net/ipv4/ip_forward
# ^D
logout
%
🙂
Stefan
On 5/13/24 18:52, to...@tuxteam.de wrote:
Now share your ideas :-)
$ su -
Password:
# echo 1 > /proc/sys/net/ipv4/ip_forward
# ^D
logout
$
I don't need no stinkin' sudo :-)
regards,
chris
>> 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.
Or to be more precise, .bashrc (and any file that's read from it like
.bash_aliases) can run anything the bash CLI ca
I think I have found my way,adding this line to /etc/sudoers :
marietto ALL=(ALL) NOPASSWD: /usr/bin/iptables
and on the warp script :
sudo /usr/bin/iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
On Mon, May 13, 2024 at 3:20 PM wrote:
> On Mon, May 13, 2024 at 09:17:31AM -0400, G
Since this happens so often, I'm trying to offer a recap.
As others have noted, the above
sudo echo 1 > /proc/sys/net/ipv4/ip_forward
won't work, since it runs echo under sudo, but the file opening
(that pesky ">") happens in your shell, which is probably running
unprivileged (otherwise, what
Nobody has yet applauded this glorious implementation
of the 1960s GOTO statement in *Bash*?!
* Mario Marietto [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, Ma
Mario Marietto 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
I don't have those typos in the code. The typo has been to copy the content
of the script by hand on the email message.
On Mon, May 13, 2024 at 6:30 PM Will Mengarini wrote:
> Nobody has yet applauded this glorious implementation
> of the 1960s GOTO statement in *Bash*?!
>
> * Mario Marietto [2
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),
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 que
[image: Istantanea_2024-05-13_17-37-39.png]
Can someone explain to me why user "marietto" can't execute the command
iptables as root,without password ? thanks.
[image: Istantanea_2024-05-13_17-40-21.png]
On Mon, May 13, 2024 at 5:19 PM Mario Marietto
wrote:
> There is still a problem. If I log
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 aut
> You don't need to, but I definitely think he does. 🙂
^^
[ Oh, bias, when will you leave me alone? ]
Stefan
I've found that solution on the Internet. It wasn't the only solution that
I found,but that form won the challenge because it has found my mind ready
to detect that it could have worked. Maybe I could have used while,but
after 1 hour of thinking I didn't understand how and I resigned. The same
for
>> > 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
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 "/$
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 *di
Le 13/05/2024 à 15:03, Richmond a écrit :
Erwan David 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 wor
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 th
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 ':$')
Richmond (12024-05-13):
> sudo bash -c "echo 1 > hello"
Use sh for that.
Regards,
--
Nicolas George
Erwan David 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
>>
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 wo
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
On Mon, May 13, 2024 at 02:53:18PM +0200, Nicolas George wrote:
> to...@tuxteam.de (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 ki
to...@tuxteam.de (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
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
signature.asc
Description: PGP signature
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 xt
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.
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
fi
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
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 “
> 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
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
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 no
--> 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 automati
Hello to everyone,
Richard,thanks. I've launched the script inside the .profile file that's
inside the root folder and it worked. Thank you.
Plan B : From time to time the cloudflare connection stops working,so there
is the needing to repeat these commands :
warp-cli disconnect
warp-cli connect
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
53 matches
Mail list logo
