Every time I'm connecting to the server due to the screen irssi command, I gain new nick with underline (like: "nick_" and now it's already "nick____").
I don't have to say how annoying it is.
I tried to use command 'screen -Ur irssi', but then "There is no screen to be resumed matching irssi." appeared.
Start irssi and enter these lines:
/network add -autosendcmd "/nick {your nick}" {server name}
/save
In these lines you might notice two "variables":
{your nick} - change to your nick;
{server name} - server's name (i.e. Freenode).
This sets Irssi to change your nick automatically (it runs a command after connection).
Also, you might like checking out Irssi documentation related to the subject: documentation
alternate_nick
An alternate nickname to use if your preferred one is already taken.
nick $IRCNICK
Your main, preferred nick.
Related: resource
Related
I have a project called kos and it's a simple SUID tool,
recently as a lot of people in private have been asking
me I added authentication storing/remembering,
but it's not that good
So what happens basically is:
Verify that the user has entered the correct password
If the password is correct set the temp_validate_user variable to true and temp_validate_user_id to the authenticated user's ID (e.g. 1000)
In the run_command function, after setting the appropriate IDs (uid, euid, gid and egid) do:
If the last modified timestamp is less than the set max ammount, remove /var/kos/<user id>
Else if temp_validate_user is still set make sure /var/kos exists, if not make it then make a file called /var/kos/<user id> (e.g. /var/kos/1000)
To put it simply we just store a file called /var/kos/<user id> and then check if its last modified timestamp is less than the max ammount
But we got a problem
Even though the dir is root-only with kos you can
get root and if you verify once you can do this:
while true; do echo | kos touch "/var/kos/$(id -u)"; done
And when the user authenticates the file will be
be updated all the time meaning you can have infinite
root bypass
So the question is, is there ANY better way to do this,
I really need to find a better way because as more of the
time passes I keep getting more and more worried about
it and I can't think of anything
Oh and if it wasn't clear already, I don't want to
use PAM or anything else other than pure C or C++
Related commits and lines of code:
https://github.com/TruncatedDinosour/kos/commit/cbcc1346d76b0c47bb4658a1b650de11f74a2727
https://github.com/TruncatedDinosour/kos/blob/main/src/config.h#L62
https://github.com/TruncatedDinosour/kos/blob/main/src/macros.hpp#L40
https://github.com/TruncatedDinosour/kos/blob/main/src/main.cpp#L37
https://github.com/TruncatedDinosour/kos/blob/main/src/main.cpp#L46
https://github.com/TruncatedDinosour/kos/blob/main/src/main.cpp#L23
https://github.com/TruncatedDinosour/kos/blob/main/src/main.cpp#L175
https://github.com/TruncatedDinosour/kos/blob/main/src/main.cpp#L185
https://github.com/TruncatedDinosour/kos/commit/f8c4e79e798c0ffaa15df9d1d77fb91b54e61599
https://github.com/TruncatedDinosour/kos/commit/9ee54bbd01281016d1170c37b0a6cd23433b1227
Thanks for the answers in advance :)
Questions and answers
What's your goal?
Store that the user has logged in for x ammount of seconds
then if x seconds have passed invalidate it,
but until x seconds hasn't passed don't ask the
specific logged in user to enter their password
As #ThomasWeller sudo does the same thing, meaning it's secure
enough, I dropped the terms on the dir from 744 to 711 and file
perms from 744 to 600
Thank you #ThomasWeller once again
I recently added ripgrep to my list of vim plugins and, immediately after installation, I began receiving this error message whenever I loaded up vim:
Error detected while processing /Users/my_macbook/.vim/plugged/vim-ripgrep/plugin/vim-ripgrep.vim:
line 149: E1208: -complete used without -nargs
Press ENTER or type command to continue
Opening the offending file and reviewing lines 148-149 reveals:
148 command! -nargs=* -complete=file Rg :call s:Rg(<q-args>)
149 command! -complete=file RgRoot :call s:RgShowRoot()
I am well & truly out of my depth here, especially considering that this error was generated by simply installing the plugin; I've made 0 changes to the underlying file (vim-ripgrep.vim).
Has anyone encountered a similarly chronic error after installing ripgrep and, if so, how did you resolve it?
Congratulations, you have found a bug in a FOSS program. Next step is to either notify the maintainer via their issue tracker or, if you know how to fix it, submit a patch.
Case in point, the author assigns a completion method, -complete=file, but custom commands like :RgRoot don't accept arguments by default so the command makes no sense as-is: you can't complete arguments if you can't pass arguments.
It only needs a -nargs=*, like its upstairs neighbour, :Rg, to work properly and the error message is pretty clear about it:
line 149: E1208: -complete used without -nargs
See :help -complete, :help -nargs, and more generally, :help user-commands.
As the other answer stated, it is a bug in this plugin. There is a currently open pull request to fix this: https://github.com/jremmen/vim-ripgrep/pull/58 Unfortunately, the repository is currently unmaintained, so it is unlikely to be merged any time soon. This active forks page may help you identify a new maintainer.
Until there is a new maintainer for vim-ripgrep, I suggest checking out that branch in your ~/.vim/plugged/vim-ripgrep directory and reopening vim.
I met the functionally same error on VIM plugins while using vim ~/.vimrc.
My met error liking yours:
Error detected while processing /Users/my_macbook/.vim/plugged/vim-ripgrep
/plugin/vim-ripgrep.vim:
I fixed the upstairs with the below:
cd /Users/my_macbook/.vim/plugged/vim-ripgrep/plugin/
git pull --rebase
END!
If you are using vim-plug, try to change
Plug "jremmen/vim-ripgrep"
to
Plug "miyase256/vim-ripgrep", {'branch': 'fix/remove-complete-from-RgRoot'}
Here are detail steps:
comment Plug "jremmen/vim-ripgrep"
:PlugClean
add Plug "miyase256/vim-ripgrep", {'branch': 'fix/remove-complete-from-RgRoot'}
:PlugInstall
I own a couple domains, I would just like to renew them using the CLI. I see a thing to renew using the QT client, but my domains are in my CLI wallet, not my QT client wallet.
Credit to https://forum.namecoin.org/memberlist.php?mode=viewprofile&u=1057&sid=ecc0431681aea878e1add77c55dcd741
First of all make sure your CLI client is synchronized, i.e. getinfo (or better: getblockcount) gives you the same block number as you get at http://namecoin.webbtc.com/ or http://explorer.namecoin.info/stats/block_count.txt
You should also check if the amount of NMCs in your wallet is sufficient for the renewal command(s). One renew or update attempt costs you 0.005 NMC or less.
Renewing a name is identical to updating a name. In both cases you use name_update, and the command line looks like this:
./namecoin-cli name_update name "value"
Example: if you own the name d/hrdwdmrbl (which translates to the domain name hrdwdmrbl.bit) then your name renewal command could be:
./namecoin-cli name_update d/hrdwdmrbl "{\"map\":{\"\":\"93.184.216.34\"}}"
Notes:
- The example above is correct for Linux or Mac OSX. I think it looks slightly different in MS-Windows. It may need double or triple backslashes for escaping the inner doublequotes (e.g. "{\\"map\\" ... )
- Older Namecoin client versions use ./namecoind instead of ./namecoin-cli
- If you get it wrong then you either get an error message and you can try again instantly, or you don't get an error message and you have to wait for at least 1 confirmation before you can update again. You can always check the results of your commands with listtransactions
At the moment I have to hard code the names of servers on my vimrc in order to either make it different on the remote machine. This is done by conditional statement using hostname() function in vim. I want to make the conditional to be based on the status of remote connection and not on the hostname. So...
The first possible solution I found was using the following bash command in system():
cat /proc/$PPID/status | head -1 | cut -f2
This does not work because I use GNU screen and this will not detect my connection status properly.
The second possible solution I am exploring right now is using who am i This reliably shows whether or not remote connection has been made from which client, but I have trouble getting it working with system()
if substitute(system('who am i'), "theclient", ????, "") == ""
...
How could I get ???? to extract my client name somehow??
Even if the second solution works, allowing me to use .vimrc for many different remote machines, it is still tied to one client. I want the conditional to work in all remote session, regardless of the client name. So I am wondering, is this possible?
The following line allows me to create a variable that detects the remote connection status:
let g:remoteSession = ($STY == "")
Now you can surround the lines that you want to be ignored in the remote connection via:
if g:remoteSession
...
endif
On a side note, I do not know how expensive it is look up the environment variable compared to the global variable, but I am guessing the difference is negligible. The system call in an environment like cygwin where fork() is inefficient, it is worth doing the optimization.
Instead of adding conditional logic to a shared ~/.vimrc, you could alternatively source system-local settings. I use the following:
" Source system-specific .vimrc first.
if filereadable(expand('~/local/.vimrc'))
source ~/local/.vimrc
endif
" Stop sourcing if inclusion guard exists.
if exists('g:loaded_vimrc')
finish
endif
" Common settings of .vimrc here...
I find this more scalable than trying to maintain an ever-changing list of hostnames in a central location.
I am using WMI (prototyping everything in VBScript first, as examples are more plentiful and it removes VBScript/Python impedence) to connect remotely to a fresh PC (we will call this PC2). Most Win32_* classes can be remotely read, yet Win32_Printer returns an empty set when queried, but only when I query remotely. The resulting SWbemObjectSet always has a .Count of zero. No error. I can connect to PC1 and receive a SWbemObjectSet with a non-zero .Count, can iterate through it, etc. If I run the script locally (after removing the superuser username and password from the .ConnectServer method, naturally), I get a non-zero .Count back and can iterate through it. Even if I foolishly use my own Domain Administrator account, the problem persists. The Script:
strComputer = "nnn.nnn.nnn.nnn"
username = "DOMAIN\superuser"
password = "thisisaverygoodpassword"
Set objSWbemLocator = CreateObject("WbemScripting.SWbemLocator")
objSWbemLocator.Security_.ImpersonationLevel = 3
objSWbemLocator.Security_.AuthenticationLevel = 6
Set objSWbemServices = objSWbemLocator.ConnectServer(strComputer, "root\cimv2", username, password)
Set colSWBemObjectSet = objSWbemServices.ExecQuery("Select * From Win32_Printer")
WScript.Echo colSWBemObjectSet.Count & " Found."
For Each objPrinter in colSWBemObjectSet
For Each Property in objPrinter.Properties_
If TypeName(Property.Value) = "Variant()" Then
Wscript.Echo """" & Property.Name & """, """ & TypeName(Property.Value) & """, ""Skipping ..."""
Else
Wscript.Echo """" & Property.Name & """, """ & TypeName(Property.Value) & """, """ & Property.Value & """"
End If
Next
Next
Commenting and error checking have been omitted for brevity.
It does not appear to be a firewall problem.
Reason 1: Where a firewall blockage does exist, I receive an error
back from SWbemLocator, "The RPC server is unavailable."
Reason 2: I can access and run through the WMI class Win32_ComputerSystem
with ease.
It does not appear to be a username/password problem.
Reason 1: I can retrieve information from Win32_ComputerSystem.
Reason 2: I ought to get an error.
It does not appear to be an OS version problem:
Reason: PC2 and PC1 are both running Windows 7 Professional. PC1 is running the 64-bit version, PC2 the 32-bit.
Although I started trying to reach a 32-bit machine from a 64-bit server, it does not appear to be a 32-bit vs. 64-bit problem.
Reason 1: I added a value of 32 for __ProviderArchitecture in a SWbemNamedValueSet prior to my .ConnectServer attempt (with that SWbemNamedValueSet in the arguments to no avail), although I was unable to later add that same context to the .ExecQuery method of the connected server without a type mismatch operator.
Reason 2: I later ran the script from a 32-bit server with the same result.
It does not appear to be a corrupted WMI problem.
Reason: Once I stop using credentials, I can run the script from the target machine itself and receive a result set with more than zero items and can iterate through it.
It does not appear to be a credential/namespace mistake within my script.
Reason: Using WBemTest.exe from the same source machine and using identical username, password, authentication level, impersonation level, namespace, and so forth, I receive the same null set for an answer.
It does not appear to be an issue of WMI Namespace security on the target machine.
Reason 1: Logging in to the target machine with the same credentials as the script uses generates results.
Reason 2: Win32_Printer is in the same namespace as Win32_ComputerSystem. Win32_ComputerSystem works.
Reason 3: After using the Wmimgmt.msc Microsoft Management Console (MMC) to give the superuser full permissions, starting in the root namespace, propagating to "This namespace and subnamespaces," rebooting, and checking again, I still receive the same empty set.
It does not appear to be the respective OUs of PC2 and PC1 that are the problem.
Reason: I swapped the OUs each machine was in and rebooted. No change.
It does not appear to be the Local Computer Groups:
Reason: I made the membership of groups in PC2 look like PC1 and rebooted. No change.
It does not appear to be something magical about Win32_Printer in that remote access does not work.
Reason: I can read PC1's Win32_Printer class.
It does not appear that my WQL is unusual.
Reason: "SELECT * FROM Win32_Printer" is my test case.
It does not appear that my DCOM settings are off.
Reason: They appear identical when I go through PC1 and PC2.
I have even gone so far as to hit the Trace logs in WMI-Activity, print them out for both PC1 and PC2, then sort by GroupOperationID, OperationID (the TimeCreated SystemTime is not granular enough and EventID seems ... out of order. I can see events from the following actions:
IWbemServices::Connect
Start IWbemServices::ExecQuery - Select * from __ClassProviderRegistration
Start IWbemServices::GetObject - __Win32Provider.Name="WmiPerfClass"
Start IWbemServices::ExecQuery - references of {__Win32Provider.Name="WmiPerfClass"}
Start IWbemServices::GetObject - Win32_Printer
Start IWbemServices::ExecQuery - Select * From Win32_Printer
Provider::CreateInstanceEnum - Win32_Printer
in both sets of logs, and if I sort by GroupOperationID, OperationID they appear to happen in identical order. Sorting by EventID shows a somewhat different order. That's the closest I can see to a difference. I'm stumped at this point.
I know this verges perilously close to a system administration issue.
Found this link in the win32_printer spec page referring to this problem http://www.lansweeper.com/forum/yaf_postsm18178_WMI-Security-PowershellLansweeper.aspx#post18178 It appears only printers installes for this user are returned, not all printers on the system. So if you've never logged on to the remote system under the credentials of the user you are using to enumerate the printers then you get an empty result.
Looks like you've had a good shot at it. ServerFault might yield something more...
It's a long shot, but I once heard terminal services being disabled aparently caused issues when issuing WMI queries...
Edit:
This may not apply, but could be worth a look: AD Delegation