Re: [PLUG] MediaWiki configuration
On 4/20/23 19:25, Keith Lofstrom wrote: Any recent MediaWiki deployers on the list? For many years, [...] IF YOU HAVE SET UP MEDIAWIKI RECENTLY, CAN YOU POINT ME AT GOOD /RECENT/ TUTORIALS? I haven't, and have no experience with MediaWiki (and still nominally maintain a teetering MoinMoin wiki), but have you looked at this: https://www.mediawiki.org/wiki/Manual:Installing_MediaWiki -- Russell Senior russ...@pdxlinux.org
[PLUG] MediaWiki configuration
Any recent MediaWiki deployers on the list? For many years, I have operated many old MoinMoin (Python) wikis on many old distros. MoinMoin isn't getting much maintenance attention, while Python is evolving beyond compatibility with MoinMoin code. MediaWiki (PHP), the engine underneath Wikipedia, currently has the majority share of new wiki deployments, and is actively (perhaps TOO actively) maintained and enhanced. So, I hope to "futureproof" my wikis by converting them to MediaWiki. There are cheesy scripts for that. As I write this, I have not yet successfully configured a functional MediaWiki instance. There are many tutorials online about that, but most are years out of date. For example, procedures for setting up mysql, rather than the current mariaDB. I'm probably not asking the right questions or looking at the best tutorial websites. IF YOU HAVE SET UP MEDIAWIKI RECENTLY, CAN YOU POINT ME AT GOOD /RECENT/ TUTORIALS? Perhaps the most useful thing would be an "ls -lR" listing of the files and programs and libraries used by a recent implementation of MediaWiki, so I know what files are supposed to be there, permissions and ownerships and sizes. And yes, I will sign an NDA if necessary, and can even offer boilerplate forms for that. Keith L. P.S.; I know there are rental MediaWikiFarms, but I hope to continue integrating my wikis with legacy html pages and online executables. MediaWiki has many extensions that might help with this. -- Keith Lofstrom kei...@keithl.com
Re: [PLUG] 3rd party vpn Defense evasion
Agreed, HR and legal should absolutely be engaged and on-board given the risk level. On Wed, Apr 19, 2023, 4:43 PM Ted Mittelstaedt wrote: > > For employees it depends if they are exempt or not. Any supervisory > employee who can fire people is automatically considered exempt and many > other employee classifications (such as programming) are considered exempt > as well. (exemption is once more IRS and state taxing authority > determination that the company has no say over) > > If the employee is exempt from overtime then it's illegal for the company > to require that they work a certain number of hours, or at certain times. > If the company DOES tell the employee this (that they have to track their > time) then the employee can hit them for mandatory overtime (if they exceed > 40 hours) > > Exempt/non exempt classifications are more commonly referred to as > salaried/hourly employees. > > Long and short of it is you cannot use an online form to consider "work to > be valid" for a salaried AKA exempt employee. Salaried employees are paid > BY THE JOB not by being logged into something for a certain time. > > Companies quite often forget that putting someone like a programmer on > salary is a two way street. The benefit from the company's point of view > is they don't have to pay overtime for one of those > work-round-the-clock-push times. But in exchange for that, the employee > also doesn't have to work 40 hours every week either. A decent salaried > employee keeps an eye on time since it's an important metric for how much > work is reasonable to expect a salaried employee to do but it is NOT the > absolute metric. > > Companies who have tried to do it differently - that is, not pay OT and > make you work late during crunch time - and still make you work 40 hours - > regularly end up paying very large fines and back salary to people when > they get sued. It's healthy for that to happen for owners of those > companies to get slapped silly for trying to exploit workers from time to > time. > > Once more as I keep saying this needs to be handled from an employee > management standpoint via managers and HR not from the IT department trying > to play God and the managers being wussies and afraid to talk to employees. > > Is it simply that a large number of IT people are on the autism spectrum > and have social anxiety disorder that they will literally waste weeks of > company time on elaborate technical solutions that can be handled in 5 > minutes by a manager walking up to an employee and saying "hey dude you > know that thing you are doing with the VPN, well knock it off" > > Or is it that their anxiety disorder and desire to Play God just drives > them to believe that every other employee in the company is trying to screw > IT??? > > Sheesh!!! > > Ted > > -Original Message- > From: PLUG On Behalf Of Daniel Ortiz > Sent: Wednesday, April 19, 2023 1:39 PM > To: Portland Linux/Unix Group > Subject: Re: [PLUG] 3rd party vpn Defense evasion > > Disclaimer: some of the following if not all could be wrong. > > Wouldn't it be easier to deal with the credentials side to avoid this > problem in the first place? To illustrate what I mean, here's a theoretical > idea that while it might be flawed (like potential security failures), > could be useful in terms of guidance. When an employee logs in, it sends an > email to their company Gmail account complete the login in procedure. They > click the link to a Google form which requires them to be logged in to > their company Google account for the submitted form to either work or be > considered valid. Once, it's submitted, a program will allow them to finish > the login process. Also, doing something with a company Google account > could be helpful since Google records the devices you logged in with, which > if a company can check that, they can see if there is any suspicious > devices. > > On Wed, Apr 19, 2023 at 10:29 AM Ishak Micheil wrote: > > > We're chasing this from data science side as well. As far as charting > > the pattern of activity and flag anomalies. > > This should trap the subs since he/she won't be checking email, > > responding to chat messages etc, or hopefully time of activity could > give us clues. > > > > I do agree, there are many VPN commercial services and they will never > > advertise servers properties, besides there's lots of other open-VPN > > options. > > > > We shall conquer! > > > > On Tue, Apr 18, 2023, 3:21 PM Ted Mittelstaedt > > > > wrote: > > > > > > > > > > > -Original Message- > > > From: PLUG On Behalf Of John Jason > > > Jordan > > > Sent: Tuesday, April 18, 2023 2:00 PM > > > > > > >It would be nice if VPN services advertised how effectively they > > > >stop > > > others from finding out who and where you really are. > > > > > > They are never going to do this because they are constantly tweaking > > their > > > proprietary protocols to get around firewalls, and they don't want > > > the firewall
Re: [PLUG] Transferring public key shows error
If you are using public key authentication (which you want), you need that turned on, not commented out. This stuff pretty much works out of the box, but it seems like you've figured out a way to screw it up. Generally speaking, putting it in a blender and pressing the puree button isn't the best way of figuring out how it works. On Thu, Apr 20, 2023 at 10:09 AM Rich Shepard wrote: > On Thu, 20 Apr 2023, Rich Shepard wrote: > > > Since the only two external servers to which I connect have my public > key, I > > don't need it locally. Yes? > > Not so. > > I commented out #PubkeyAuthentication yes on both salmo and caddis; > rebooted > both. > > From salmo: > $ ssh caddis > ssh: connect to host caddis port n: Connection refused > > From caddis: > $ ssh salmo > rshepard@salmo: Permission denied (public key) > > I'm totally stymied. > > Rich >
Re: [PLUG] Transferring public key shows error
On Thu, 20 Apr 2023, Rich Shepard wrote: Since the only two external servers to which I connect have my public key, I don't need it locally. Yes? Not so. I commented out #PubkeyAuthentication yes on both salmo and caddis; rebooted both. From salmo: $ ssh caddis ssh: connect to host caddis port n: Connection refused From caddis: $ ssh salmo rshepard@salmo: Permission denied (public key) I'm totally stymied. Rich
Re: [PLUG] Transferring public key shows error
On Thu, 20 Apr 2023, Russell Senior wrote: Without looking it up, passphrase is the encryption that protects the private key on the client system, so that the super user (or others able to read files) can't just read/copy your private key. Russell, Since the only two external servers to which I connect have my public key, I don't need it locally. Yes? If in the future I'm away from my office and need to check mail or get a file from my server (salmo) my risk of using my password rather than my passphrase should be low. The advice suggested by the internet is to check /var/log/auth.log on the server side (caddis) to see why it's rejecting your connection. Slackware has no auth.log since it's not on salmo or caddis. I'll disable password authentification on both hosts and try to connect between the two hosts. Thanks, Rich
Re: [PLUG] Transferring public key shows error
Without looking it up, passphrase is the encryption that protects the private key on the client system, so that the super user (or others able to read files) can't just read/copy your private key. The passphrase never leaves your machine, or the ssh process that is used to authenticate to the server. The advice suggested by the internet is to check /var/log/auth.log on the server side (caddis) to see why it's rejecting your connection. On Thu, Apr 20, 2023 at 9:31 AM Rich Shepard wrote: > On Thu, 20 Apr 2023, Russell Senior wrote: > > > "debug2: we did not send a packet, disable method" > > That seems relevant. > > Russell, > > To me, too. But, does that mean disable passphrase authentification in > /etc/ssh/sshd_config on both machines? > > If I do that what does it mean when I login to github or my website host, > both of which ask for, and accept, my passphrase. Are these two different > from intra-LAN ssh? > > Thanks, > > Rich > >
Re: [PLUG] Transferring public key shows error
On Thu, 20 Apr 2023, Russell Senior wrote: "debug2: we did not send a packet, disable method" That seems relevant. Russell, To me, too. But, does that mean disable passphrase authentification in /etc/ssh/sshd_config on both machines? If I do that what does it mean when I login to github or my website host, both of which ask for, and accept, my passphrase. Are these two different from intra-LAN ssh? Thanks, Rich
Re: [PLUG] Transferring public key shows error
"debug2: we did not send a packet, disable method" That seems relevant. On Thu, Apr 20, 2023, 06:57 Rich Shepard wrote: > On Wed, 19 Apr 2023, Russell Senior wrote: > > > I find it is pretty helpful to read the messages. If the messages are too > > terse, add verbose or debug flags. Then read what it says. > > Is there anything listening on caddis's port n? > > Russell, > > My apologies; I completely forgot to use the -v option to ssh. > > Looking at the output of 'ssh -vvv salmo' (because it has more details than > 1 or 2 vs) shows everything working until a public key packet is sent and > received, yet there's no reason I see why it quits then: > > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug3: receive packet: type 21 > debug1: SSH2_MSG_NEWKEYS received > debug2: set_newkeys: mode 0 > debug1: rekey in after 134217728 blocks > debug1: Will attempt key: /home/rshepard/.ssh/id_ed25519 ED25519 > SHA256:hYzUmycAbseyYetGxTEN+LN56sffyLVysiwVB7S3ZKQ > debug2: pubkey_prepare: done > debug3: send packet: type 5 > debug3: receive packet: type 7 > debug1: SSH2_MSG_EXT_INFO received > debug1: kex_input_ext_info: > server-sig-algs= > debug3: receive packet: type 6 > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug3: send packet: type 50 > debug3: receive packet: type 51 > debug1: Authentications that can continue: publickey > debug3: start over, passed a different list publickey > debug3: preferred publickey,keyboard-interactive,password > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Offering public key: /home/rshepard/.ssh/id_ed25519 ED25519 > SHA256:hYzUmycAbseyYetGxTEN+LN56sffyLVysiwVB7S3ZKQ > debug3: send packet: type 50 > debug2: we sent a publickey packet, wait for reply > debug3: receive packet: type 51 > debug1: Authentications that can continue: publickey > debug2: we did not send a packet, disable method > debug1: No more authentication methods to try. > rshepard@salmo: Permission denied (publickey). > [rshepard@caddis ~]$ > > Caddis' public key is in salmo's authorized_keys, and vice-versa. > > Rich >
Re: [PLUG] Transferring public key shows error
On Wed, 19 Apr 2023, Russell Senior wrote: I find it is pretty helpful to read the messages. If the messages are too terse, add verbose or debug flags. Then read what it says. Is there anything listening on caddis's port n? Russell, My apologies; I completely forgot to use the -v option to ssh. Looking at the output of 'ssh -vvv salmo' (because it has more details than 1 or 2 vs) shows everything working until a public key packet is sent and received, yet there's no reason I see why it quits then: debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: receive packet: type 21 debug1: SSH2_MSG_NEWKEYS received debug2: set_newkeys: mode 0 debug1: rekey in after 134217728 blocks debug1: Will attempt key: /home/rshepard/.ssh/id_ed25519 ED25519 SHA256:hYzUmycAbseyYetGxTEN+LN56sffyLVysiwVB7S3ZKQ debug2: pubkey_prepare: done debug3: send packet: type 5 debug3: receive packet: type 7 debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs= debug3: receive packet: type 6 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug3: send packet: type 50 debug3: receive packet: type 51 debug1: Authentications that can continue: publickey debug3: start over, passed a different list publickey debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /home/rshepard/.ssh/id_ed25519 ED25519 SHA256:hYzUmycAbseyYetGxTEN+LN56sffyLVysiwVB7S3ZKQ debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey debug2: we did not send a packet, disable method debug1: No more authentication methods to try. rshepard@salmo: Permission denied (publickey). [rshepard@caddis ~]$ Caddis' public key is in salmo's authorized_keys, and vice-versa. Rich
