Re: sshd problem on WS2008R2 64bit

2019-03-06 Thread Stephen Paul Carrier
On Wed, Mar 06, 2019 at 03:44:36PM -0800, Stephen Paul Carrier wrote:
> PW=`dd if=/dev/random bs=15 count=1 | base 64`

That should be 'base64' of course, without the space.

--S

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: sshd problem on WS2008R2 64bit

2019-03-06 Thread Stephen Paul Carrier
On Wed, Mar 06, 2019 at 02:24:59PM -0700, Bill Stewart wrote:
...   
> For my part, I'm writing a PowerShell script that does the following:
> 
> 1) Create a local user account
> 2) Grant it SeBatchLogonRight
> 3) Create a scheduled task for it

Powershell is probably more elegant if you're familiar with it, but I
found this bash sequence that does the trick:

-
PW=`dd if=/dev/random bs=15 count=1 | base 64`
net user s4udummy /add
net user s4udummy $PW
wmic USERACCOUNT WHERE NAME=\'s4udummy\' SET PasswordExpires=FALSE

/usr/bin/editrights -u s4udummy -a SeBatchLogonRight
schtasks /create /tn wake-s4u /sc ONSTART /ru s4udummy /rp $PW \
 /tr '"$SYSTEMROOT"\\System32\\cmd.exe /c exit'
sc config cron depend= Schedule
-

I added the last statement, to make cron dependent on the Task Scheduler,
because my crontabs use '@reboot' and I am worried about cron trying
to spawn an important job before the Task Scheduler has a chance to
fix seteuid().

The dependency isn't logically sufficient as wake-s4u job needs some
time to finish.  But its working so far.  I can configure cron to start
with a delay should Task Scheduler ever lose the race.

Thanks everyone for quick attention to this problem and the workaround!

--Stephen

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: sshd permits logon using disabled user?

2019-01-25 Thread Stephen Paul Carrier
On Fri, Jan 25, 2019 at 08:34:09AM -0700, Bill Stewart wrote:
> On Fri, Jan 25, 2019 at 3:36 AM Stefan Baur  wrote:
> 
> > Not on Linux (and possibly other Unices).  There, it's perfectly valid
> > to disable an account's password login (both locally and remote), but to
> > at the same time allow ssh key file based logins for the same account.
> 
> But disabling _password login_ is an entirely separate issue from
> disabling _the account itself_.
> 
> Before the fix, it was possible to log on to sshd using a disabled (or
> locked) account.
> 
> There should be _no_ scenario where it is possible to log on using a
> disabled/locked account.

There are different paths to access and to completely disable the account
you need to close all of them.  There are many reasons to disable some
paths without disabling all paths and converting the switch that can
disable one path to a switch that will disable all paths will break
some setups and be less flexible.  (As Stefan Baur is pointing out
effectively.)

To disable ssh logins really, instead of changing the way Cygwin works
for everyone, you could do what UNIX/Linux admins do, something like
moving the user .ssh folder to .ssh.disabled.

Stephen Carrier
Systems Administrator 
BEAR (Berkeley Evaluation & Assessment Research) Center
Graduate School of Education
University of California, Berkeley
http://BEARcenter.Berkeley.EDU/
carr...@berkeley.edu

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: msmtp depends on Gnome!?

2018-04-05 Thread Stephen Paul Carrier
On Fri, Mar 30, 2018 at 02:50:36AM +0300, Andrey Repin wrote:
> Greetings, Stephen Paul Carrier!
> 
> > My use case is a sendmail replacement (MTA) to use with cron.
> 
> ssmtp
> 
> > ssmtp does this poorly (and hasn't been maintained since 2009).
> 
> Please clarify. What does it not do for you, and what needs maintenance?

It seemed to be losing messages.  Maybe that's what non-queueing MTA's
do if the server doesn't respond.  But there was no indication of a
specific error other than the nonzero exit status.

I didn't mean to complain about ssmtp so much as switch to something
that implements the same basic idea but is currently maintained.
Maybe switching will fix the problem, maybe it won't.  Still worth
changing, I think.  And msmtp is a Cygwin package and should have
realistic dependencies.

I had recently discovered this page:
https://wiki.archlinux.org/index.php/SSMTP, which has the best
documentation I have seen for ssmtp.  Still, the page itself suggests
using msmtp instead.

Jon Turney reports (in this list) that the msmtp dependencies have been
fixed and I confirm that they are.

Thanks to all!

Stephen Carrier


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: msmtp depends on Gnome!?

2018-03-29 Thread Stephen Paul Carrier
On Thu, Mar 29, 2018 at 03:24:50PM -0400, Will Parsons wrote:
> On Wednesday, 28 Mar 2018  9:40 PM -0400, Brian Inglis wrote:
> > On 2018-03-28 15:50, Stephen Paul Carrier wrote:
> >> msmtp is billed as a light-weight SMTP client and I would like to use
> >> it with cron instead of ssmtp.
> >> What's not light-weight is its dependency on libgnome-keyring0 which
> >> has more dependencies that eventually bring in Gnome.  This is for a
> >> headless workstation.
> >> Is it possible to remove or replace this dependency so that msmtp can
> >> be installed without enlarging the size of the install by such a factor?
> >
> > Look at the other packages under the Mail category e.g. email, mailutils, 
> > nmh.
> > I've poked around with some of them, and most are pretty easy to set up and 
> > use,
> > depending on your requirements.
> 
> That may be true, but it is still surprising that msmtp should depend
> on libgnome-keyring0.  I don't use msmtp under Cygwin, but I do under
> FreeBSD, and under the latter platform, my version of msmtp seems to
> depend on:
> 
> bash-4.4.12_3
> ca_root_nss-3.36
> indexinfo-0.3.1
> gettext-runtime-0.19.8.1_1
> 
> This obviously will not translate directly into Cygwin, but it
> certainly suggests that the OP's comment is justified.  (I'll have to
> admit, I don't know why even bash should be a dependency.)

My use case is a sendmail replacement (MTA) to use with cron.  I want to
configure it to send correctly formatted e-mail to a smarthub.  That is
all I need.  Cron expects something with sendmail-like commandline
interface.  ssmtp does this poorly (and hasn't been maintained since 
2009).  msmtp is reputed to do this also, more reliably, more flexibly,
and had a new version released in 2016.

I don't need a MUA client like email, nmh, or a local delivery agent
like comes with mailutils.  These are not sendmail workalikes.

I understand that Gnome may include a library used by msmtp.  Maybe that
library could be packaged separately?  It sort of defeats the purpose
of providing light-weight network utility if a desktop needs to be
installed just to get a miscellaneous library function. It is not even
a graphical program.

Also, maybe this dependency is just an oversight?  Also, maybe
libgnome-keyring0 is really standalone and doesn't actually depend on
a desktop.  Wherever this issue comes from it would be great and I would
appreciate the effort if anyone can correct it.

Thanks!

Stephen Carrier

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



msmtp depends on Gnome!?

2018-03-28 Thread Stephen Paul Carrier
Dear cygwin people,

msmtp is billed as a light-weight SMTP client and I would like to use
it with cron instead of ssmtp.

What's not light-weight is its dependency on libgnome-keyring0 which
has more dependencies that eventually bring in Gnome.  This is for a
headless workstation.

Is it possible to remove or replace this dependency so that msmtp can
be installed without enlarging the size of the install by such a factor?

Thanks!

Stephen Carrier

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



new setup.exe doesn't collapse package sets in full view.

2016-12-13 Thread Stephen Paul Carrier
I downloaded the new setup program (2.877, 32-bit) and ran it on a
cygwin installation that hadn't been updated in over a year (2008R2).
I first got the Pending view, OK, then switched to Full and found that
the packages were not aggregated into tabs-- they were in one very long
alphabetical list.  I am wondering whether the more convenient tabbed
view is still available and if others are also seeing this issue.  

I tried a different download source, same issue.  I have tried with
server that hadn't been updated in >1 year, and server that was updated
last week.  Same issue.

Can the tabbed view be retained as an option, even for pre-existing
installations?  Thanks.

Thanks,

Stephen Carrier

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Installer names not meaningful enough

2016-12-05 Thread Stephen Paul Carrier
On Thu, Dec 01, 2016 at 11:37:41AM -0500, Ian Lambert wrote:
> On December 1, 2016 8:54:57 AM EST, cyg Simple  wrote:
> >
> >
> >On 12/1/2016 8:25 AM, Vlado wrote:
> >> On 1.12.2016 13:51, Eliot Moss wrote:
> >>> I think that including the version of the setup program could be
> >helpful
> >>> - I tend
> >>> to add it (renaming the file by hand).  However, clearly we've lived
> >>> with things this
> >>> way for a long time ...
> >
> >More than a score years.
> >
> >> 
> >> I disagree.
> >> I have a script to update Cygwin. This script checks for new version
> >of
> >> setup, downloads, verifies signature, etc. Things would become much
> >more
> >> complicated with variable setup file name.
> >> Finally: Why should I care about the exact version number of setup?
> >> Script makes backups of the old setup files like setup.exe.0001,
> >0002,
> >> ..., just for a cause, but never in the past I did have to looking
> >for
> >> the setup with exact version number.
> >> 
> >
> >The only reason would be if you had an older version of the .ini file.
> >When the data prerequisites of the .ini file change there is a new
> >version of setup to handle that.

Right, and the way to learn if this is the case is to run setup.  I learn
that a new version is available by running the old version.

Running setup is also the way to find out what is the version.

I don't mind renaming the file myself, but would really appreciate any
way to know from the cygwin.com front page exactly which version of the
setup-*.exe is on offer.  (The current version of Cygwin DLL is useful,
but not the same thing.)

Stephen Carrier

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: python 2.7.12 pip install with extensions fails with warning: "__BSD_VISIBLE" redefined

2016-11-28 Thread Stephen Paul Carrier
>> Hi -
>>
>> The newest version of cygwin with python 2.7.12-1 fails when pip
>> installing packages that require compilation.  For example, pycrypto
>> fails:
>
>FWIW this patch to pycrypto also fixes it:
>
>https://git.sagemath.org/sage.git/tree/build/pkgs/pycrypto/patches/cygwin/disable-std-c99.patch?id=aaa9b7fc887b64ba1dba7cba16061f598a097b75
>
>The problem only occurs when trying to build with the C99 standard if
>Python itself was not.

I fixed this issue by editing /usr/include/python2.7/pyconfig.h to comment
out the second line of:

/* Define on FreeBSD to activate all library features */
#define __BSD_VISIBLE 1

This seemed like the right thing to do since Cygwin isn't FreeBSD, and
the problem went away.

Is this an oversight in python-devel package?  Issue doesn't occur in
32-bit version.

Stephen Carrier
Systems Administrator 
BEAR (Berkeley Evaluation & Assessment Research) Center
Graduate School of Education
University of California, Berkeley
http://BEARcenter.Berkeley.EDU/

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple